| RE: [eclipse.org-architecture-council] The Art of Project ReleaseNaming |
|
I see some conflicting requirements here. On one hand we call
for aligning major/minor version numbers with API compatibility and maturity (e.g.,
no breaking API change within a major version; provisional API should stabilize
within x number of version etc.). On the other hand some would like conformity
of version numbers of different components in a release train. However projects
don’t progress at the same pace. I understand a release train to be a set of
components that promise to work with each other and preferably take advantage
of each other’s new features. We are not asking each project to put in similar amount
of change to their APIs or feature set in a new train. I suggest that we leave versioning a decision of each project. Perhaps
Eclipse foundation should market each release using only the train name and
refrain from using the version number of any train participants (i.e., Galileo
!= 3.5). Each participating project may decide to use the train name alone, or
a train name + version number (e.g., BIRT Galileo or BIRT 2.5 (Galileo)). What
we do need is a quick reference page for users to find out what versions of
what projects constitute an Eclipse train release, i.e. , Eclipse Galileo =
Platform 3.5 + Mylyn 3.2 + BIRT 2.5 + … Regards, Gary From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Mik
Kersten I assume this implies that we’re not going to mix the marketing
release name (e.g., “Helios”) with the engineering version number, and keep the
version numbers unconstrained. It may be the best compromise, but I have
a concern that’s similar to the one John states below. A lot of people
still consider the version of the Galileo coordinated release to be 3.5.
It was tweeted as #eclipse35. When I get asked about Mylyn version by
those who aren’t Eclipse insiders I’ll find myself saying “Mylyn version that
shipped with Eclipse 3.5”. The ECF download page states: “ECF 3.0 Install
via P2 Repository -- for use with Eclipse 3.5”. I always make an effort
to use “Galileo” and proper version numbers, but then end up saying things
like: “Make sure that you’re on
Eclipse 3.5, with Mylyn 3.2, WTP 3.1 and ECF 3.0.” Which tends to result in a confused stare as someone tries to
pick their way through our 3.x version soup. For users that just want the latest thing, we’re in a pretty
confusing state due to the various version number, so the naturally fall back
to the version of the Platform. The fact that so many of the numbers are
3.x just adds to the confusion. (That seems be a point of convergence for
API stabilization.) Taking the user’s point of view, this has made me secretly wish
that we had a coordinated opt-in version number for projects, pegged to the
Eclipse Project’s. Projects that are big enough to effectively market
their version number, such as BIRT and WTP, could opt out. For
integrators, bundle/API version numbers would evolve as they do now. In
other words, just as platform versions its components separately from the
coordinated 3.5 version number, projects would still use their own internal
versioning, but could advertise their release version as part of Eclipse 4,
then Eclispe 5, and avoid the scenario where a few years down the road we’re
trying to communicate a dozen different 3.x and 4.x versions. Mik From:
eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Chris
Aniszczyk On Thu, Jul 2, 2009 at 11:04 AM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
I think the Planning Council will name Eclipse releases monotonically now. What I mean by this is that this year it was Galileo, next year it will be Helios and the following year it will be something that starts with an "I" There's order implied there so it's easy to talk about things and understand when they came out. Cheers,
|