[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Version names rather than Version numbers
|
Hi Ed,
one problem I see with having "Indigo", or "Juno" in the feature name is
that most of our projects are built for both Indigo, Juno, Helios or
Galileo. For instance EMF Compare 1.2 is the latest version for Indigo,
Helios, Galileo and Ganymede though it did only participate in the
"Indigo" release train. Same for Acceleo.
On the other hand I agree having a "single juno/indigo/other composite
update site" for each project looks like a considerable improvement and
might make things simpler. But as we're supposed to build both on 3.8
and 4.2 for Juno, we might have two of them for this cycle.
Cédric
Le 05/12/2011 08:25, Ed Willink a écrit :
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
