[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Kepler SR2: Advice on feature-rename migration paths needed
|
Do you need to do any "real" migration from 1.x to 2.x, for example
workspace data format upgrades and the like, or it is purely feature
rename? I vaguely remember there was way to tell p2 that one installable
unit replaces another, which directly supports your feature rename scenario.
--
Regards,
Igor
On 1/10/2014, 7:17, Andreas Sewe wrote:
Hi,
the Code Recommenders project contributes both to the Kepler and Luna
simultaneous releases. So far, we have contributed version 1.x to Kepler
(R and SR1) and 2.x to Luna (M1-M4). Given that version 2.x has proven
to be stable (we are at 2.0.4 at the moment) we would like to contribute
Code Recommenders 2.x to Kepler SR2.
There is one problem, however: Between version 1.x and 2.x our features
got renamed quite a bit.
So, while we contributed a 1.x feature called "o.e.r.feature.rcp" to
Kepler so far, to Luna we are contributing a 2.x "o.e.r.simrel.feature"
which includes a 2.x "o.e.r.rcp.feature". Now, we have a 1.x to 2.x
migration feature ("o.e.r.feature.rcp") available that itself includes
the 'real' 2.x feature ("o.e.r.rcp.feature").
Graphically
o.e.r.simrel.feature 2.x
+- includes -> o.e.r.rcp.feature 2.x
o.e.r.feature.rcp 2.x
+- includes -> o.e.r.rcp.feature 2.x
Of course, our simrel repository could just continue to include
"o.e.r.feature.rcp", now in version 2.x, and users upgrading from Kepler
SR1 to SR2 would simply upgrade "o.e.r.feature.rcp" from 1.x to 2.x and
automatically get the included "o.e.r.rcp.feature". This works.
Alas, it also means that the "o.e.r.feature.rcp" feature has to float
around indefinitely. We cannot ever remove this from our stable update
site as people willing to upgrade within the 2.x strain of Code
Recommenders might have obtained their "o.e.r.rcp.feature" as an include
of ""o.e.r.feature.rcp" -- and that include AFAIK fixes the precise
version for "o.e.r.rcp.feature".
Now, a way to solve this upgrade problem would be to switch to the
following feature structure:
o.e.r.feature.rcp 2.x
+- requires >= 2.0.0 -> o.e.r.rcp.feature 2.x
Users upgrading their 1.x "o.e.r.feature.rcp" feature to 2.x would then,
from the same update site, also install the latest "o.e.r.rcp.feature"
to satisfy the requirement. Now, after some time during which those
users willing to upgrade have done so, we can simply remove the
"o.e.r.feature.rcp" migration feature; it's requirement will continue to
be satisfied by any future update of "o.e.r.rcp.feature".
As far as the simultaneous release is concerned, the question is,
however, whether we are allowed to supply two features connected by
"require" (rather than by "include") in our b3aggrcon for the
simultaneous release? I unfortunately wasn't able to find anything on
this in the Wiki [1].
Any advice is greatly appreciated.
Andreas
[1] <http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements>
