https://pantsbuild.org/ logo
Join SlackCommunities
Powered by
although it’s a little bit out of line with conven...
# development
w
although it’s a little bit out of line with convention (because 
2.16.0
is not released yet), i think that we should cut 
2.17.0a0
and the 
2.17.x
branch now to keep (closer to) our six week target.
the 2.16.x release is being finalized over in https://pantsbuild.slack.com/archives/C0D7TNJHL/p1683909006064199 … so hopefully early next week … not too much overlap.
b
2.18.x is when we've committed to tightening our compatible ICs right? And therefore building/uploading less?
w
iirc, yes.
🎉 1
h
I'd prefer not to, but would definitely insist on not creating 2.18.x docs until 2.16.0 is out
w
agreed re: docsite creation. @happy-kitchen-89482: if you have time to make a 
release-process.md
edit to update our convention there, it would be appreciated. there is no point creating it early anymore.
but i disagree re: waiting longer on the stable branch… the consensus is for 6 weeks currently, and we should try to stick to it. should discuss how to either 1) make the rc process shorter, or 2) adjust the release schedule in another thread though.
h
I just don't agree with that consensus. I think it should be 6 weeks+only one unreleased stable branch pending. If we can't stick to a 6 week cadence in practice then we can't pretend that's not the case or we'll continue to rack up unreleased stable branches that we can't overtake...
Unless we declare 2.17.x to be a catch-up release that isn't fundamentally different than 2.16.x I suppose
But then what's the point?
w
@happy-kitchen-89482: ok, then i would suggest building consensus around a new value, and getting it changed in the docs: https://www.pantsbuild.org/v2.17/docs/release-strategy#stable-releases
b
(FWIW I wait until rc to start testing at $work. And the last 2 releases, that's uncovered bugs. Sometimes, like this time, there's a rinse-and-repeat involved)
(I'm still testing 2.16 🙂)
h
How are we going to get people to test 2.17 when they're not on 2.16 yet
w
the point is to prevent 2.17.x from getting larger
the larger the release is, the longer the release cycle, etc. it’s a vicious cycle.
should discuss how to either 1) make the rc process shorter, or 2) adjust the release schedule in another thread though.
h
Fair
well, let's do 2.17.x for now, as it is policy
But the alternative vicious cycle is we end up with ever more concurrent unreleased stable brunches
w
yea. tightening up the 
rc
timeline will be important.
i started this thread on the topic after the last team meeting: could discuss there perhaps. https://pantsbuild.slack.com/archives/C0D7TNJHL/p1683587623576919
2.18.x is when we’ve committed to tightening our compatible ICs right? And therefore building/uploading less?
i am tempted to do this ASAP once 
2.17.x
is cut, but waiting until the release job changes have stabilized (and been picked, if necessary) might be good. hopefully mid next week.
Open in Slack
PreviousNext
Powered by