[cross-project-issues-dev] Confusion trying to install outdated add-ons

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi Ed,

I just found this message drowned way down in my inbox.

I fully agree with the problem statement (it's too easy to install old, outdated versions of stuff rather than the recommended line-up).

I've seen this multiple times by our customers too : They installed "Wind River Workbench 3.3" and not knowing what Eclipse Train it was built on they installed a wrong version of JDT or PDE on top of it. And the p2 error messages in such a case a dependency conflict occurs with trying such a thing are not helpful at all, nobody can understand them.

I disagree with the proposed solution of naming features etc. after the release train. Problems include eg
- A feature may remain unchanged between 2 train releases, eg Eclipse Platform CVS .. makes no sense renaming just for the sake of the name
- Multi-version releases like Cedric mentioned
- In custom products the Eclipse train name may also not be known

I feel like a better approach would be making a line-up (like Indigo, or Juno) have more influence such that the line-up could "recommend" particular versions of add-ons to be installed and/or warn when a non-recommended version of a known IU is about to be installed.

How does that sound?
Who would care opening a bug to further explore solutions to the problem ?

-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: Monday, December 05, 2011 8:25 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Version names rather than Version numbers

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