[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
Sent: Thursday, July 02, 2009 1:01 PM
To: 'eclipse.org-architecture-council'
Subject: RE: [eclipse.org-architecture-council] The Art of Project ReleaseNaming

 

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.

 

Cheers, 


--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk