[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
Link ?
that we cannot now ship 4.2.0 as a Kepler maintenance release, so we
will have to re-activate the maintenance branch.
Ok.
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.
Ok.
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.
I think we agreed, but there is no plan for such transition, AFAIK. In
principle, I don't have any releng related assignment.
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
