Re: [tools-pmc] Xtend2

[Sven Efftinge <sven@xxxxxxxxxxx>]

Hi Stephan,

please find my comments inline.

On Dec 15, 2011, at 1:32 PM, Stephan Herrmann wrote:

> Hi Sven,
> 
> as a listener (not member) of tools-pmc I'm curious about your
> plans regarding migration strategies for adopters of Xtend2.
> 
>> [...] changing the namespace of the bundles to 'org.eclipse.xtend2'.
> 
> I assume the same change of namespaces will also apply to all
> packages inside the bundles?

Yes, but they are all internal.

The public API is the language (i.e. it's syntax and semantics) and the library.
There is no intention to change them in an incompatible way and the library already has the 
suggested namespace. So we don't need to change anything which was previously 
published publicly apart from the feature and plugin names to be installed.

> 
> As an industrial user of Xtend2 through Xtext I'd like to mention
> that the rapid releases of Xtext already make it difficult to keep
> pace with HEAD. Maybe the split of the projects is a good time
> to expand the plan section on compatibility and API guarantees,
> drawing a clear line, which aspects may possibly change in the
> future and which are stable.

See above.

> (as recently discussed in cross-projects the project plan for
> Xtext seems to be lagging behind :) ).

It's up to date now.

> Putting on my hat as a fellow language designer:
> Please bear in mind that for a project that defines a new 
> programming language not only the API but also the language
> specification should be covered by any statements about
> stability and compatibility. In this context I wonder if it would
> help to split the language documentation into a language
> specification that is "legally binding" and user documentation
> in an educational style. Currently the documentation is more
> of the second kind.

You are right the documentation is meant to be readable by users. That's why it's called "User Guide".
It should contain everything which is interesting for users. Please file a bug report about the things you're missing.
Note that, it shouldn't contain details only relevant for language implementors. That is what
a specification would be made for.

An official statement about compatibility is indeed very important. For Xtend it would be
like what I outlined above. The language and the library is intended to be backward compatible as long as there's no major version increment. 

Btw we have always had such a statement for Xtext as well, even in the first couple of years where the statement simply was, that 
"everything might change".

> 
> Sorry if this sounds conservative, but I think these considerations
> are relevant for the planned restructuring:
> When creating a new Xtend2 project, what will be the start level?

2.3

> From the language specification I'd personally say: version 0.8.5.

As we don't plan to write a lengthy language specification unless someone needs it, it might never reach 1.0.

> Or should the new project automatically inherit the version 2.3
> from its former parent project? Note that the language Xtend2
> is much younger than Xtext itself. Has that language ever seen
> a 1.0 release?

Yes, that's why it's called Xtend 2
see http://www.eclipse.org/Xtext/xtend/#history

Xtend 1 is part of m2t.xpand. Xtend 2 is an incompatible rewrite (similar to e.g. Python 3) and was firstly released in June (2.0.0).

Regards,
Sven