Hi Martin, the main point is, that Xtext was released with Juno in version 2.3.x and had a dependency to Juno's EMF version 2.8. Now we have Kepler Stream where Xtext 2.4 and EMF 2.9 is included. IMHO, if one tries to install Xtext from Kepler in her/his Juno SRx, she/he should not wonder that this Xtext version will probably require some other bundles from the Kepler common repository e.g. EMF 2.9 or eclipse platform 4.3 instead of 4.2.
My opinion to the version numbering: if projects would increment their version each time their dependencies do, or if one the dependency includes a performance change, some of eclipse projects would/should have a three digit major version now. I'm not quite sure, that changing the version 4-5 times every year, helps adopters, and which is more important, I'm sure it would not reduce user's confusion. Kind regards, Dennis. Am 27.06.2013 um 21:41 schrieb Oberhuber, Martin: > Hi John, > > I agree with you in principle, but in this case Kosta does have a point. > > The Version Numbering document that you cite in [1] says > “The minor segment number must be incremented when a plug-in changes in an > "externally visible" way. Examples […] include […]significant performance > changes” > > When XText decided to require EMF 2.9 in order to benefit from its > significant performance improvements, it would have made sense to release it > as XText 2.5 with a minor version increment; those Version Numbering > Guidelines should be followed to avoid adopter confusion. > > Now this hasn’t been done for Kepler, I’m not sure why it hasn’t been > detected earlier, and I’m not sure what the immediate implications are (other > than EdW having to stick to XText 2.4.1 and not being able to upgrade yet). > To me it sounds that Ed Merks’ proposal of making sure that EMF 2.9 is a > fully working drop-in replacement for EMF 2.8 in all cases is the right > approach moving forward. > > Thanks, > Martin > -- > Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River > direct +43.662.457915.85 fax +43.662.457915.6 > > From: [email protected] > [mailto:[email protected]] On Behalf Of John > Arthorne > Sent: Thursday, June 27, 2013 9:22 PM > To: Cross project issues > Subject: Re: [cross-project-issues-dev] What is a maintenance release > > I realize this was a rhetorical question, but the requirement is that > projects are capable of working with the version of their dependencies that > is shipped in the same simultaneous release. In this case the Kepler version > of XText requires the Kepler version of EMF. This is quite reasonable, and > although some projects support multiple older versions of their dependencies, > there is no requirement to do so that I'm aware of. > > In both Eclipse versioning [1] and the more widely cited semantic versioning > [2], version increases don't have transitive effect (unless dependencies are > re-exported). I.e., just because the major or minor version of something I > require changes, doesn't mean my version has to increase by the same > magnitude. More concretely, the fact that EMF's minor version increased does > not imply that XText's minor version must increase. If you follow such a > transitive policy to its logical conclusion you will see the version numbers > of individual components become meaningless, impossible to manage, and > everyone would end up needing to increase their major version number just > about every release. > > [1] http://wiki.eclipse.org/Version_Numbering > [2] http://semver.org/ > > John > > > > > From: Ed Willink <[email protected]> > To: Cross project issues <[email protected]>, > Date: 06/27/2013 02:51 PM > Subject: Re: [cross-project-issues-dev] What is a maintenance release > Sent by: [email protected] > > > > Hi Ed > > I am trying to understand what if any release rigour exists in the > Eclipse release policies; indeed if there are any policies at all. > > There is clearly a large discrepancy between my expectation and what I > observe in practice. > > Regards > > Ed Willink > > On 27/06/2013 18:50, Ed Merks wrote: > > You've also had ample opportunity to notice the bounds on Xtext's > > contributions to the release train, so it's not clear what you're > > hoping to achieve after the fact by involving a broader audience. > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
