|Re: [mdt-ocl.dev] Kepler/Luna releases|
I think the (temporary) release branch has a number of advantages
a) changes from master cannot squeeze in after releng starts.
b) auto-builds will not happen for master during release
c) releng commits can be reverted, so that the eventual merge to master can be compressed to what worked, free from typos and other stupidities
If the 'a' builds are not often required we can go for the target name directly.
a) Fast-forward merge the 'release' branch with 'master'
b) Switch the (only one needed) job configuration to 'release'
c) Build x.y.z.Mn at +1 allowing N/I repo contributions (RESOLVE_N4S = true)
d) Build x.y.z.Mna at +3 using only S repo contributions (RESOLVE_N4S = false,. the default)
if practice 'a' build reuses all old features and plugins, no 'a' build needed
if practice 'a' build creates a newer feature or plugin, do a real 'a' build
e) Switch the job configuration back to 'master'
The RESOLVE_N4S parameter was really easy to do and avoids impact on the publishing scripts, download pages, other places that I don't know about.
On 17/08/2013 17:27, Adolfo Sánchez-Barbudo Herrera wrote:
"S" and "S" is much better; all the downstream stuff just sees pairs of Ses with slightly different dates. No real problem.
Anyone using the milestones repo just sees a new build appear.
We just need to add a Boolean build parameter RESOLVE_I4S so that the rmap resolution filter allows I repos when doing an S-build (for all dependencies other than platform and EMF).
I didn´t like that solution, because you have a global parameter which only makes sense when an specific value of another parameter is selected. In any case, if you prefer that rather than reviewing the publishing scripts, it´s fine to me.---
Side issue: what is "resolve.target.platform" for? It seems to always be true. Is it for some private testing config that I don't understand?
I can´t help too much here. This comes from doing what other relengs did when I started to work on buckminster. In practice, I don´t benefit from it, but yes it´s a property supposed to be changed when working in local if you wanted to avoid downloading a new target platform every time you do configuration tests in local. Since in hudson, workspace and target platform are cleaned prior to build, the TP always need to be downloaded.
Anyway our eventual workflow could be
Fast-forward merge the 'release' branch with 'master'
First time I heard of a "release" branch in this context.
+1 build ('Core')
Do an S build from 'release', without alias, with RESOLVE_I4S true. Promotion populates the .../milestones repo (not .../milestones/core). Aggregator picks it up from milestones.
(Download pages and repos will therefore show this build as S2013.... so users hopefully not be confused with the true 4.2.0M1 build.)
We are officially a +1 project, so in my opinion we do need a 4.2.0M1 build at M1+1. Having something different will confuse users rather than help. Instead, I´d use the traditional convetion of using the "a" suffix to use at M1+3.
If the +1 build fails in the aggregator, we will have to choose between delaying contribution until our dependency has contributed, or finding some temporary workaround.
Delayed contribution to release train makes sense to me. We´d still have a proper milestone repository to which downstream projects should build against.
+3 build ('Tools')
Do an S build from 'release', with alias such as 4.2.0M1, with RESOLVE_I4S false. Promotion populates the .../milestones repo (not .../milestones/tools). Aggregator picks it up from milestones.
As commented, I´d produce a 4.2.0M1a. We could even build at +2 once our +2 dependencies are in place. The old dicussion of requesting to be a +2 project can be taken up, if accepted we would avoid having to create a 4.2.0Mxa every milestone.
If the +3 build fails, fixes/workarounds are developed in the 'release' branch. Once successful, 'release' and 'master' are merged.
I´m not sure we need a release branch, just fixes on the master (which should be only produced by last minute +2 projects).
_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this message.Version: 2013.0.3392 / Virus Database: 3211/6585 - Release Date: 08/17/13
Checked by AVG - www.avg.com
mdt-ocl.dev mailing list
Back to the top