Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Important structural change in Eclipse Neon
Hi Kaloyan,

thank you for testing and for the feedback!

I don't want to introduce new product IDs, because there are so many places where they are used internally during the build, and there are many users outside building upon those IDs (e.g. Mylyn). To me they are like API and nothing that we should change. And it is not only the product ID that would need a change, it is also the ID of the features that would need to be changed.

What I could imagine to avoid having frustrated users after an 'upgrade' would be a change in the p2 metadata with a p2.inf file for the product and for the feature that prevents the upgrade from earlier versions (because the result would be broken/unexpected). This would be my proposal to move forward.

But I'm on vacation this week. I reserved enough time to work on this weeks milestone release. While I could do the small change in the p2.inf files that I mentioned above, I won't have time to work on additional things on top.

Thanks,
Markus







On 17 March 2016 at 20:56, Kaloyan Raev <kaloyan.r@xxxxxxxx> wrote:

Hi,


I've just tested the update from Mars.2 to a local build of the EPP packages with the structural change. The update finished without error, but all features, that are declared as "root" in the new version, were simply uninstalled.


IMHO, this is pretty bad. Users who used to update their EPP installation in the past, now will find this workflow broken.


As a solution I suggest that we introduce new product IDs for the EPP packages which apply the structural change. This way we will prevent the broken update.


In addition we may continue maintaining the existing product IDs with the existing structure (at least for 1-2 releases), so all users, who used to update their EPP installations, can continue doing it.


Greetings,

Kaloyan


From: epp-dev-bounces@xxxxxxxxxxx <epp-dev-bounces@xxxxxxxxxxx> on behalf of Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx>
Sent: Tuesday, February 23, 2016 10:29 PM

To: Eclipse Packaging Project
Subject: Re: [epp-dev] Important structural change in Eclipse Neon
 
Hi Markus,

Thank you for the explanation! I'm OK with the upgrade not working from Mars -> Neon. As long as it works for Neon -> Neon+1 (unless the user installs incompatible stuff),  I think the trade-off is reasonable.

Marc-Andre

From: epp-dev-bounces@xxxxxxxxxxx [epp-dev-bounces@xxxxxxxxxxx] on behalf of Markus Knauer [mknauer@xxxxxxxxxxxxxxxxx]
Sent: Monday, 22 February 2016 2:27 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] Important structural change in Eclipse Neon

Hi Marc-Andre,

no, an upgrade from the old structure to the new structure is unfortunately not supported. Maybe someone comes up with a good idea/solution but I have my doubts.

Under the hood it uses a feature in Tycho that allows to define features as "root" features in a product definition. These root features behave like other features that have been installed into a package by the user; because of this it is possible to update and/or remove them independently, but they are *really* independent. This brings the advantage that parts of a package can be updated much easier and independent from the package definition as requested by so many, but I admit that it has its consequences, too, i.e. the package maintainer is only responsible for the initial package layout.

While this may sound scary to some of us (I used to be in this group in the past!), I'd like to compare it now with a Linux installation, e.g. a Ubuntu or a Fedora Linux. They all allow you to install a basic system that includes most of the tools required by an average user. But this user has always the freedom to deinstall/remove certain parts, install other software, update parts or all of it.

Now a package maintainer has always the freedom to remove the installMode="root" in the product definition; this has the consequence that this feature cannot be removed easily by the user, but then an update of the EPP package metadata is required in order to trigger an automated update in the field.

Example: The CDT project releases an important update. With the old package structure, or without installMode="root", a rebuild of the EPP package and its metadata is required. With the new structure the CDT project can trigger an update independent of EPP.

Sorry for the longer mail... I hope it helps to understand the situation better.

Thanks,
Markus



On 22 February 2016 at 16:46, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
Hi Markus,

Is it expected that upgrading from Mars (old structure) to Neon (new structure) will work correctly?

Thanks!
Marc-Andre

From: epp-dev-bounces@xxxxxxxxxxx [epp-dev-bounces@xxxxxxxxxxx] on behalf of Markus Knauer [mknauer@xxxxxxxxxxxxxxxxx]
Sent: Monday, 22 February 2016 3:22 AM
To: EPP Developer Mailing List
Subject: [epp-dev] Important structural change in Eclipse Neon

Hi package maintainers,

please read through this mail because your action is required...

Last year we enabled a weekly check for updates in Eclipse Mars packages, in Eclipse Neon I'd like to go one step further and make it possible for users to upgrade parts of a package. There have been many discussions, sometimes here on this mailing list, and in recent months within the Planning Council [1] about that topic.

Maybe you remember that we used to define all dependencies (and based on that the content) of a package in its feature. While this approach was the one that was working from the very beginning, it has its drawbacks. The major drawback is that 'check for updates' only searches for updates of the root feature which is the package feature itself. Unless we update this one, p2 doesn't look for updates of any of the other features that make up a package. Most users expect a different behaviour these days.

In order to change this it is necessary to define the content of a package on its root level, i.e. with root features. I did this change in Mars for a single package (RCP/RAP), but now I'd like to roll out this change in *all* packages for Eclipse Neon.

For that reason I prepared one Gerrit change for each package as documented here in this bug:

  Bug 332989 - Allow parts of a package to upgraded or removed
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=332989#c19

Now I'm asking every package maintainer to review his/her change in Gerrit, and to vote at least with a +1 in Gerrit (feel free to +2 and to merge: then I have a little less work to do). All changes are referenced and linked in the above bug report. Please read my individual commit comment carefully; if a package needed some kind of special treatment I described this in the comment.

These changes are moving the dependencies from the feature to the product root level, and with that all the features get their own lifecycle, i.e. they can be updated independently, they even can be removed. The change should not change anything else.

If you think you need to optimise your package structure, I'd suggest you take this as a new base and open a bug for further discussion.

If anything is unclear, or if there are questions, please ask here on the mailing list.

Thanks and regards,
Markus

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev


Back to the top