Re: [cross-project-issues-dev] What is a maintenance release

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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 <ed@xxxxxxxxxxxxx>
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>, 
Date:      
 06/27/2013 02:51 PM
Subject:    
   Re: [cross-project-issues-dev]
What is a maintenance release
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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