I'd be very happy to release internally from master, as long as it goes hand in hand with a policy of reverting problematic commits. By which I mean "if there's a bug caused by this commit that we can't immediately fix, and that would be reasonably considered a bug by people other than Twitter, we will revert it while it's investigated". I think that strikes a reasonable balance between making progress, being flexible, and not chasing our tails too much. (But I'd also like to gauge people's thoughts on "on rare occasions we may push a weird side branch with a cherry pick or two off of an old master commit", because if people aren't cool with that at all I'd want to reconsider the strategy)

i think being able to eventually avoid weird side branches with said cherry-picks is a good goal to shoot for

For sure, but we're not there yet, and the road there is either aggressive reverting or stable branches, imo. I prefer aiming for master being green and reverting if we need to (with little side branches if we get desperate). But if people don't agree, I'd rather know that our community prefers stable branches going in, than constantly be clashing over the approach.

see above re: no longer having any sort of stable release at that point. https://groups.google.com/d/topic/pants-devel/axaMpP-Z8nU/discussion for context

Yeah, I'm fine with stable releases being a thing we do as a project for the community, rather than for us as Twitter. It's not obvious to me that those things need to be linked (though it's been a convenient way to do things until now :))

they would be linked in that in order for them to be high quality, we'd actually need to vet and presumably release them internally

Can go either way. We could also release whatever we happened to release internally (and treat externally reported regressions like we would internal - patch master and re-release matter)

that's not particularly stable, especially if you discover something more than a few days later

If it's going to work for us internally is going to have to become sufficiently stable.

that's a slightly different definition of stable i think. stable in this context also means that if someone is using

1.14.0

and they need a bugfix, they can bump to

1.14.1

without... removing a bunch of deprecations or something

That sounds like the "hopefully rare but may be occasionally necessary" weird side branches I was describing wanting people to be ok with coming up from time to time...