Release strategy

[OlivierBondu]

@blinkseb , @delaere

to continue and follow-up the discussion on #60 outside of the PR itself :

• I think it still is nice to have tags, not to force everyone to have the latest master, but maybe once a week is too much... every time someone intend to present results to CMS ?
• if bugfixes happen shortly after a tag, we should tag them
• in the particular case of Support for producers scheduling #60 : there is no need to tag as this is preparatory for now: no feature uses this at the moment ?

[blinkseb]

I think we should see the framework like a tool by itself, with its own life and release cycle. Whenever we decide, we tag a new release and inform everyone. Then, analyses are free to update or not. But I agree it does not solve the main question: when should we tag a new release?

I don't have strong opinions on this one, but I think we should always tag and release after a bug fix: this is the only way to ensure that everyone knows about it. For other features, I guess it depends if these are wanted for some analyses or not.

We also need a some point to discuss branching. We'll need to support multiple CMSSW release, and we'll also need to backport bug fixes. For example, we need many code / python changes to upgrade to CMSSW 7.4.12, which will break compatibility with 7.4.10. But, 7.4.10 is sill needed to run over MC and Run 2015B / C, so we need to keep it around. I'd suggest the following:

• master is deleted and converted to a CMSSW_7_4_10 branch.
• We create a new branch from CMSSW_7_4_10 named CMSSW_7_4_12.
• Need development occur on the latest version branch, and backported to other branches if needed

Nomenclature is for example only, I think it should be great to indicate it's up to 7.4.10 and 7.4.12 and more.

Again, I'm not sure it's the best way to do it. Any ideas?

[delaere]

Concerning the release frequency, I think that the baseline should be tag whenever one needs to present outside (meeting, note, PAS, ...) . This should in principle be a minor release (major on exceptional cases).

Then, for each release in use, there should be bugfix releases whenever needed.

On the contrary, I would not tag new developments before a milestone. This would only create entropy. Also weekly releases would get us to rel 1.52.0 before we notice it. Maybe we can agree to tag on a ~monthly basis if nothing happened in that period.

About branches, I am fine with your proposal.

[OlivierBondu]

agreed for the branches and for the proposals on my end !

[blinkseb]

So I propose today to:

• Rename master to CMSSW_7_4_10m (m stands for minus, which min 7.4.10-)
• Create CMSSW_7_4_12p (p for plus, 7.4.12+) from CMSSW_7_4_10m.
• Merge Add a way to access other analyses from analyzers #62 into CMSSW_7_4_12p. This way, we avoid breaking all the analyses in 7.4.10.

Once done, I'll send an email to cp3-llbb detailing the procedure to switch from the non-longer-existent master branch to the newly created one.

[OlivierBondu]

ok for me!

also for the tagging: where do we discuss the need for new tags ? we open an issue / milestone to make sure info is propagated ?

[blinkseb]

I have created the two new branches, but I've left the master branch in place to not break all the clones out there. I've recreated the 2 PR but this time against the correct branch.

Concerning the tagging, it's a good question. Opening an issue sounds like a good idea. In any case, we should always create a new release when tagging. This way, info is propagated and we can document what has changed since the last tag.

[OlivierBondu]

For the follow-up: recent PRs were not backported back to CMSSW_7_4_10m, I don't think anyone needs it any longer ?

And also a proposal: should we keep this thread open for whenever someones asks for a tag ?

[OlivierBondu]

Any objection if I create a tag today ? (for the branch CMSSW_7_4_12p)

[blinkseb]

Please go ahead :)

2016-01-11 13:13 GMT+01:00 Olivier notifications@github.com:

Any objection if I create a tag today ? (for the branch CMSSW_7_4_12p)

—
Reply to this email directly or view it on GitHub
#61 (comment).

Sébastien Brochet

[OlivierBondu]

Some 80X samples start coming (e.g. TTTo2L2Nu), so a 80X framework branch will be created soonish 😄

[blinkseb]

I'm working on creating the new branch, stay tuned ;)

[blinkseb]

Branch created and opened for business !