Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Kepler/Luna releases

On 15/08/2013 09:47, Ed Willink wrote:

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.



4.1.1 with very few changes as Kepler SR1.
4.2.0 with latest improvements concurrently as a recommended Kepler

4.2.1 with very few changes as Kepler SR2.
4.3.0 with latest improvements concurrently as a recommended Kepler

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'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'.


         Ed Willink
_______________________________________________ mailing list

Back to the top