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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev