|Re: [mdt-ocl.dev] Kepler/Luna releases|
Hi On 15/08/2013 13:00, Adolfo Sanchez-Barbudo Herrera wrote:
Indeed. Recent cross-project-dev discussion reveals that there has been a total failure of communication.On 15/08/2013 09:47, Ed Willink wrote:Hi The new "releases must be released a month before SR RC1" policy meansLink ?
It's possible, but the release review + one month stable + RC1/2/3/4 time is a long delay. Easier to use the earlier release with minor fixes.So 4.1.1 with very few changes as Kepler SR1. 4.2.0 with latest improvements concurrently as a recommended Kepler install. 4.2.1 with very few changes as Kepler SR2. 4.3.0 with latest improvements concurrently as a recommended Kepler install.I understand that we can't ship 4.2.0 for Kepler SR1 due to time constraints, however if properly scheduled, a 4.3.0 could be shipped for Kepler SR2, right ?, unless I'm missing something else since the last decision of having 4.2.0 for Kepler SR1.
I think we agreed, but there is no plan for such transition, AFAIK. In principle, I don't have any releng related assignment.I'm hoping that the only difference is in the *.rmap, and with sensible includes, much of that can be shared too. If both 'core' and 'tools' builds build everything then it's just a matter of expanding the built features, probably to what is already in the 'branch' build. I think the only 'difficulty' is in naming of the updatres folders.In principle I had in mind, one build, a similar configuration which we have for the branch-tests, but some work is needed for the parts that branch-tests doesn't do (basically the publishing part). However, I understand from what you say, that indeed we still need to make some distinction between a +1 build and a +3 one, to feed the build with different repositories (I/S -even N- repositories at +1 and just S repositories at +3).
I guess that just a new build.type option (S1 and S3 replacing S) could work for us, but you would need to carefully revise of the publishing part (that build.type usage).
I'm not keen on a new build type.
In any case, I would plan any transition after M1 to avoid stress. For SR1 RCs may be it's not even worthy to do it.
Certainly SR1 will use the SR0 technology.
(Only emergency commits on master between +1 and +3). Ah! perhaps it would be better if we built from the 'release' branch, so that fast-forward merging the 'release' branch with 'master' is a releng activity avoiding any accidental contributions from 'master'. Regards Ed Willink _______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3211/6578 - Release Date: 08/14/13
Back to the top