|
I was about to reply something
similar...
but if we promote adopting the platform version number for
identifying project versions, what about projects like CDT 6.0 which would have
to version down (6.0 -> 4.0) ?
I like the idea of continuing to rev up project versions as
we do now:
-
technical versions on bundle and feature level (supported by API
tooling)
-
project release version change == maximum of all bundle version
changes, i.e. if there is ONE major bump then the project needs a major
bump
In addition to that "technical" version number which helps
existing users who upgrade, we could promote adding the train name as an aid for
new users as well as for identifying "what goes together",
e.g.
CDT 6.0 Galileo
ECF 3.0 Galileo
...
Plus some web page (auto-generated) to identify all the
project versions contributing to a train release.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
Sent: July-02-09 11:37 AM
To:
eclipse.org-architecture-council
Subject: Re:
[eclipse.org-architecture-council] The Art of Project Release
Naming
On Thu, Jul 2, 2009 at 11:04 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote:
I can across an
anecdote recently that illustrated the value of release version numbers. I
was shopping for a cordless phone to replace my old 5.8 Ghz phone.
When I last bought a phone, the choice was between DECT 2.4 GHz and
DECT 5.8 GHz, with the larger number generally being a better technology.
This time around, there was a new option: DECT 6.0. After doing some
research, I discovered that this new phone should actually be DECT 1.9 GHz,
since that is the spectrum it operates on. However, the marketing guys
thought that a smaller number would indicate an inferior product to
customers, so they pulled the "6.0" number out of thin air. As a customer I
confess I did immediately assume the higher number was the better
technology. Although the conventions are slightly different, I think this is
a perfect example of why a release "marketing number" can and sometimes
should differ from an "engineering number". It also illustrates the value of
a number over simple names (if they were DECT "zebra" and DECT "camel", a
customer standing in the store wouldn't know which one to pick). All this to
say that I think it would be valuable for us to describe some
recommendations on release naming for projects. Some consistency across
projects would be great.
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.
--
Chris Aniszczyk | EclipseSource Austin | +1 860
839 2465
http://twitter.com/eclipsesource |
http://twitter.com/caniszczyk
|
