Re: [mdt-ocl.dev] Kepler/Luna releases

[Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxx>]

"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).

Regards,

Adolfo.