[cross-project-issues-dev] Version names rather than Version numbers

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

Eclipse release names such as "Indigo" have had a fantastic coordinating 
effect, but they do not go far enough. Behind the scenes users and 
developers need to understand each project's numbering system and for 
complex projects, each plugin's numbering system.

Users: I've just picked up a newsgroup message from a user who followed 
a Vogella tutorial too literally and had initial success installing 
Galileo features on Indigo before getting totally confused by a P2 
message when going a step further. If the user's choice is Galileo or 
Helios or Indigo EMF rather than EMF 2.5 or 2.6 or 2.7, many more users 
may manage to make the right choice. If the user reviews installed 
software, the version mismatch will be obvious.

Releng: OCL has moved from 3.1 (Indigo) to 3.2 (Juno M1) to 4.0 (Juno 
>M1) so all downstream project relengs must react twice. If instead 
each project published a Juno release, all downstream projects would 
react once and change all dependencies from Indigo to Juno. Once again, 
releng might make the right choice more often, and not need to know 
about project detail.

Projects: Complex projects add new plugins starting at 1.0, and so may 
have a very diverse range of versions making the overall project version 
number unhelpful.

It would seem quite straightforward to have version names in many 
locations such as update site folders, and fairly easy to allow a 
(Indigo) parenthesis on project names in the portal. Allowing version 
names in ZIP builds may also be easy. But moving further to version 
names for features may require an extra attribute in the Juno b3.aggrcon 
to define the Juno to 4.1.0 alias. Supporting plugin version names may 
require extra detail in feature files.

Is this a desirable direction?

What is necessary to enthuse, presumably P2, to support it?

    Regards

        Ed Willink