Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Kepler/Luna releases 
Hi

On 15/08/2013 13:00, Adolfo Sanchez-Barbudo Herrera wrote:

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

Hi

The new "releases must be released a month before SR RC1" policy means


Link ?
Indeed. Recent cross-project-dev discussion reveals that there has been a total failure of communication. 
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.
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.
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'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.
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