|Re: [mdt-ocl.dev] Kepler/Luna releases|
"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).
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?
Anyway our eventual workflow could be
Fast-forward merge the 'release' branch with 'master'
+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.)
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.
+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.
If the +3 build fails, fixes/workarounds are developed in the 'release' branch. Once successful, 'release' and 'master' are merged.
Back to the top