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?]
Regards
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.
[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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3204/6445 - Release Date:
06/27/13
|