Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Multi-version releases. (was Version names rather than Version numbers) 
Hi Cédric
Providing multi-version releases is very helpful, but is it helpful? Perhaps you are inadvertently aggravating the problem.
If P2 installs a 'Galileo+' version of Acceleo on Indigo as the primary install, which version of EMF, OCL, UML will be pulled in? Perhaps this is how users find it easy to get in a mess. Does P2 satisfy some unwise lowerbounds and then get confused by the conflicts?
Surely you must publish distinct (albeit binary identical) multi-version releases in order to publish the correct dependencies to P2. 

    Regards

        Ed Willink




On 05/12/2011 09:10, Cédric Brun wrote:

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



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date: 12/04/11

Back to the top