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 don't see any conficting requirements. Encoding API compatibility in your version numbers should ALWAYS be done. I don't think we are arguing about that here. The point I'm trying to bring up is that we should help projects come up with a standard way to talk about project releases. Should we start talking about "WTP Galileo" "WTP Ganymede" "WTP Europa" versus "WTP 3.0" "WTP 3.1" etc...

On a side note... let's be honest here, in general, the most successful projects at Eclipse end up on the train. Furthermore, it should be a goal to end up on the train in my opinion... it's representative of a well run project. There is the problem of what to do with projects that aren't on the 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 + â

In the end, most things are up to the project. However, nothing prevents the architecture council in encoding some good practices that projects should follow.ÂInÂmyÂcase,ÂI'mÂtryingÂtoÂargueÂadoptingÂaÂcommonÂwayÂtoÂtalkÂaboutÂprojectÂreleasesÂisÂaÂgoodÂthing...