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.
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
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@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@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
Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops
wikitech-l@lists.wikimedia.org