Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] What is a maintenance release

Hi John

My question is only half rhetorical. It is really trying to get to the root of what I do not see us providing to our consumers.

As a realistic consumer I would expect release 1.0.0 to perhaps have a few bugs. I would hope that releases 1.0.1 and 1.0.2 might address them. I do not expect to see any significant changes until release 1.1, which I expect to be upward compatible.

This seems to be a very reasonable expectation and requires that 1.0.1 and 1.0.2 make only safe bug/performance fixes; they do not include significant new development that failed to make the release date.

It seems to me that unless we ensure that service releases have a very very high probability of being improvements we damage our reputation. Industry requires stable predictable releases; they must be able to feel confident in SRs.

It seems to me that is quite acceptable, probably desirable, for projects to make significant improvements in intermediate releases, but that such improvements should NEVER appear as maintenance releases. The improvements should be available to users, but should not be forced upon them when those users thought they were getting a maintenance upgrade.

I think this should apply even to hard cases such as EGIT, where there has been such rapid progress. A version was shipped in Juno SR0 that we may now regard as unuseable in comparison to what we now have. However the Juno release review passed it as fit for release, therefore it had acceptable functionality, so it is that functionality that should have appeared less a few bugs in all Juno service releases.

[In the case of an active project such as Xtext, I find it quite amazing that anyone could even think of starting Kepler with a second maintenance release. Surely such maintenance releases could only be appropriate for inactive mature projects?]


        Ed Willink


On 27/06/2013 20:22, John Arthorne wrote:
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.



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.


        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 mailing list

No virus found in this message.
Checked by AVG -
Version: 2013.0.3345 / Virus Database: 3204/6445 - Release Date: 06/27/13

Back to the top