Re: [cross-project-issues-dev] Kepler SR2: Advice on feature-rename migr

[David M Williams <david_williams@xxxxxxxxxx>]

I barely read your original note ... I
stopped when I got to the part about "Major version change" in
"Maintenance stream". That sounds like "API change"
or some other incompatible change ... which would not be appropriate in
"SR2 maintenance". I'm sure I could be missing your point ...
but ... sometimes there is only so much you can do in maintenance, and
adopters/users simply have to wait until Luna to pick up "Major"
changes.  At least from "sim rel repo", since there, the
prime directive is "do no harm". Perhaps this policy FAQ [1]
would help? 

Given all that, if I am missing your
point, please ask the question again. 

[1] http://wiki.eclipse.org/SimRel/Simultaneous_Release_Policy_FAQ#Can%20a%20new%20project%20or%20feature%20join%20a%20Simultaneous%20Service%20Release%20%28SR1%20or%20SR2%29?





From:      
 Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
To:      
 cross-project-issues-dev@xxxxxxxxxxx,

Date:      
 01/10/2014 07:17 AM
Subject:    
   [cross-project-issues-dev]
Kepler SR2: Advice on feature-rename        migration
paths needed
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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>

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev