Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Multi-version releases. (was Version names rather than Version numbers) 
On 2011-12-05 10:54, Ed Willink wrote:

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?
P2 will either come up with the plan that best satisfy all requirements or discover that no such plan can be created. It doesn't get confused. It might report that stuff cannot be installed but that's because it has exhausted every conceivable plan possible. If it succeeds, the result might of course be confusing to the user who might have questions like - why did p2 select 2.6 when 2.7 was available?
I don't think that named versions will help resolving such confusion. It will always arise when a plethora of repositories are made available to the installer. A significant amount of them may be release-train agnostic and even come from sources other than eclipse.org. That's just the way things stand. It is that complicated and were lucky that the process of finding a workable plan is automated and efficient.
In order to get better control, you need to limit what you make available to the installer. One way of doing that, while also making sure that everything that you install is consistent, is to use the b3 aggregator to create and maintain a repository of your own. You will then discover problems early and you'll also get an end result that typically contains only one version of each thing that you want. Another advantage is that, with this repository in place locally, you will experience a lot quicker installs. 

Regards,
Thomas Hallgren
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





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

Back to the top