Re: [cross-project-issues-dev] 6 month release cycle

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

On 03/07/2013 08:22, Matthias Sohn wrote:
> I like this proposal. IMO releasing often is a good thing.
But...

For projects with simple dependencies this should work.

However for complex dependencies, occasional stakes in the ground are 
necessary.

Consider Xtext applications.

A) Eclipse (itemis) produces the Xtext (compile-time) and run-time
B) Eclipse/third party uses Xtext at compile-time to produce an XYZZY 
editor and tooling depending on the Xtext run-time
C) Users install the XYZZY tooling

The flexibility of Xtext and DI means that there are backward and 
forward dependencies between A and B since B was auto-generated against 
an earlier A but runs on a new A. In practice this means that the Xtext 
run-time API is very hard to evolve and the users may be forced to use 
the Eclipse release on which the XYZZY editor was generated by B.

As the release cycle gets faster, it will get harder for users to find a 
common platform for third party tools unless all important tools follow 
the faster release cycle very promptly. No chance.

One could argue that such tight coupling between auto-generated code and 
run-time is undesirable, but I just use Xtext as an example. I suspect 
that there are many other projects where auto-generation presents 
similar challenges.

So, Yes, let's have a half-yearly Intermediate Release, but please, 
still just one Major release per year. Let planned API breakage occur 
only prior to the last milestone of the Major release.

    Regards

        Ed Willink