|Re: [cross-project-issues-dev] 6 month release cycle|
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-timeB) 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 toolingThe 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
Back to the top