Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

set the channel description: To discuss `pre` and `stable` releases.

hey gang: re <https://rbcommons.com/s/twitter/r/3890/> and <https://rbcommons.com/s/twitter/r/3892/>

i think expectations around stable branches are a bit scattered

in particular, twitter is very afraid of falling too far behind master

and very interested in cooperating on the vetting process with the other companies

we can stay on 1.0.x for a while, but i think we've always assumed that there would be at least two stable branches in existence

and in particular, regarding <https://rbcommons.com/s/twitter/r/3892/> and `1.1.x`: we don't necessarily want that branch to live for the long long term. if it is only in existence for a month before `1.2.x` comes along, that's fine

I think a key question is what the cadence for "vetting" the master tracking branch is

We do not want to track the pre-release branch; we want to stay on stable but consume patch releases as they come

<@U053HNE90>: yes, exactly. we were hoping to mostly stay with master, and still do frequent vetted releases.

Yeah, current stable.  I consider 1.(N+1).x to be "pre"

there will be more than one stable branch, no?

so then, yea: the question is "how frequently do we create new stable branches"

Basically I want 4sq to participate in the vetting process for promoting current pre-release to latest-stable

I'm going to propose that happen once a month

i tried to highlight the existence of that question in <https://rbcommons.com/s/twitter/r/3890/> , but i don't know how to answer it.

It seems like both Square and 4sq probably don't have the bandwidth to do weekly or even semimonthly "master" vets

two weeks was what i thought folks were talking about the summit, but i might have conflated that with patches to existing stable branches

I think 2 weeks was what was discussed at the summit, though it seemed like that was based around some other tick-tock process

Another argument for less frequent stable releases is that it reduces the number of non-recent stable branches that need to have patches backported

we needn't have more than two stable branches though.

We could tool around that, but at some point there's going to be a lot of "recent" non-latest stable branches and it's not really nice to cut off backport patches after only a month or two of support