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 <[email protected]> To: [email protected], Date: 01/10/2014 07:17 AM Subject: [cross-project-issues-dev] Kepler SR2: Advice on feature-rename migration paths needed Sent by: [email protected] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
