2. Be open to cutting informal hotfix branches or tags after dev releases. Twitter could just start consuming dev releases as if they’re stable releases; we have sufficient internal release vetting that we should detect issues. The down-side here is that when things do break, it would be hard for us to make targetted fixes. We’d effectively be releasing from master, with no easy way of cherry-picking small fixes (so if we fix things, we’d either be pulling in a new master with other changes, or have to abandon that dev release until the next one). This is easy to work around by creating one-off branches based on the dev release sha, on top of which we can cherry-pick fixes. Right now we don’t do this because it feels kind of weird pushing one-off branches/tags that feel kind of Twitter-specific. In general, though, getting releases in the hands of users who will test things out and find bugs will improve the quality of the software we’re all working on, and this feels like a pretty good benefit, where the ?only drawback (as far as I can see) is that we’ll have some branches around that feel kind of weird.

@happy-kitchen-89482: ^ it sounds like you're suggesting this, but with a formalized branch created per dev release

Depends, it sounds like none of our dev releases are at the desired level of stability in practice? So you'd always need to qualify one further? How often do you anticipate doing this?

correct

But you're willing for these to be less stable than actual stable releases?

no

i think maybe we can start biweekly but weekly should be the goal

and to be clear: Daniel is interested in releasing as fast as we can. but incremental steps are good too.

i do not understand what benefit any extra branches are supposed to give us on top of a dev release

the dev release itself is very, very unlikely to be green.

You'd need to stabilize the dev release, so you can't accept new commits from master

that's a statement about right now

or you'd be chasing your tail the whole time

unless everyone stops what they're doing near the end of the week in order to allow things to stabilize

Maybe this is what patch version increments are for? We hardly use them today.

this sounds like a pretty good idea

in my mind, a patch release would be from the stable branch

Well, you can cherry-pick whatever you want into the stable branch, including entire ranges of commits?

yes. and that is the status quo

You'd have the freedom to include as much or as little as you want, it would be at the discretion of the patch releaser

i think that we avoid cherry picking "a lot" because of the stable label

But these releases will be as stable as any other stable release, right?

i think there's a very good case to be made to avoid the complexity of all of this and consume whatever the most recent dev release is directly

after running through

rcs

, yea. in theory.

complexity adds wall clock time and bitrots

@aloof-angle-91616: as daniel's original thread said, and as benjy and i agree: that would require a branching strategy for dev releases

i believe what i meant by that was not having the branching strategy

OK, so the stability of the minor release branch is not at issue. Patch releases will continue to be as stable as they've ever been. It's just that they might represent too much changed behavior than is expected from a patch release. So maybe not a good idea after all.

yea, basically. i think that increasing the flexibility of patch releases and encouraging more cherrypicking to stable branches is a spectrum. it would help, but it would not get a lot closer to "we're releasable all the time"

i really liked the idea of just making fixes to master, then doing a dev release immediately after which is what i interpreted from https://pantsbuild.slack.com/archives/C18RRR4JK/p1556213537005400

We'd only need to create a branch for those dev releases that you planned to stabilize.

ok, hadn't realized that

Yes, that was my original intention, but the issue is that to achieve true stability you have to freeze out random changes from master, and only cherry-pick what you need.

i don't know what the word "stability" means here

@aloof-angle-91616: if i'm landing unrelated patches on a friday while someone is cutting the dev release, i might break it

It means whatever qualities a release has to satisfy "Twitter can use this internally" per Daniel's original post.

@witty-crayon-22786 hopefully we all have notifications on for the #releases channel so we know when dev releases happen and avoid breaking them?

that is, imo, too much coordination.

@aloof-angle-91616 The problem is: Twitter decides to make a stable release out of .devN, so you push changes to make it stable, fix its bugs etc, to create .devN+1. Meanwhile other people have pushed changes that destabilize it in other ways. So you'd be chasing your own tail forever. That's why you need to branch.

i wouldn't be asking people to do that. we (but not me) unfortunately already do ask contributors to stop pushing potentially risky changes on our internal release schedule. the difference right now is that our internal release cadence is slow, and so there's a lot of fixes we have to make, and a longer period where we're sensitive to other unrelated upstream changes. i am trying very hard to diminish that period and reduce twitter's influence on pants's release candidates and release cycles.

@aloof-angle-91616: in our current process, once a stable branch is cut, most timing pressure is removed