Maybe we could prevent breaking things by always creating a branch for every wmf.XX number. That is, always create a new branch, even on weeks with no official branch cut. So in the case of wmf.8, we would simply branch off from wmf.7, thus extending wmf.7 for another week but under a new name, instead of creating a new branch from master.

On Tue, Jul 11, 2017 at 3:20 PM, Greg Grossmeier <greg@wikimedia.org> wrote:

Hello all,

I failed to send this notice out before when the change was made; mea
culpa.

Background:
* We start a new 1.XX-wmf.XX series after each MW 'tarball' release. For
example right now we're in the 1.30-wmf.XX series now that 1.29 is
nearing release.

The change:
* Instead of only incrementing the wmf.XX portion when a new branch is
actually deployed to Wikimedia production servers, we will increment
that number each week regardless.
** For example, last week we did not push a new branch out to production
due to the short work week. That week would have been 1.30-wmf.8. We
thus skipped wmf.8 and are now on wmf.9 this week.

Why?
We hope to make the creation of the weekly deployment branch
(1.XX-wmf.XX) automatic in the near future. This will allow us to put
that on a cron and not worry about special cases (another special case
being when we hold back the train due to a bad regression). This (every
week gets a wmf.XX number) should simplify logic in many places.

Thanks!

Greg on behalf of the Release Engineering team

PS: Yeah, we could have just gone with ISO week numbers, but we didn't
want to change too much in the version string to reduce the chance of
breaking too many other tools.
PPS: And yes, my failure to pre-announce this instead of post-announce
caused at least the ReleaseTaggerBot to break this week. Mea cupla.

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |

_______________________________________________
Ops mailing list
Ops@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ops