[Engineering] [Ops] Change to version number incrementing for weekly Wikimedia MediaWiki deploys

Tue Jul 11 20:41:49 UTC 2017

I think a branch that's never deployed is likely to confuse people more,
SWAT
immediately comes to mind (which branches do I port to?)

And while it's fixable, it would mean a non-checked-out branch wouldn't get
automatically cleaned up during our weekly pruning.

All in all: I like this move. It makes "how old is a branch" math much
easier.

-Chad

On Tue, Jul 11, 2017 at 1:31 PM Mukunda Modell <mmodell at wikimedia.org>
wrote:

> 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 at 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 at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/ops
>>
>>
> _______________________________________________
> Ops mailing list
> Ops at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/engineering/attachments/20170711/c7f24758/attachment.html>