|Re: [mdt-ocl.dev] Kepler/Luna releases|
On 15/08/2013 09:47, Ed Willink wrote:
Hi The new "releases must be released a month before SR RC1" policy means
that we cannot now ship 4.2.0 as a Kepler maintenance release, so we will have to re-activate the maintenance branch.
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.
4.4.0 for Luna.
I think we agreed, but there is no plan for such transition, AFAIK. In principle, I don't have any releng related assignment.I'll review the candidates for 4.1.1 and activate Bugzilla reviews. Are we agreed that from 4.2.0 we will merge core+tools into a 'single' build? To avoid edits; the 'core'/+1/'pre' build rmap can use the latest of I/S-builds from +2/+3 projects; the 'tools'/+3/'main' build can use S-builds only. If so, I had better have some fun with releng this weekend.
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).
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.
(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
Back to the top