https://pantsbuild.org/ logo
Join Slack
Powered by
hey folks! i’d like to propose a change to the rel...
# development
w
hey folks! i’d like to propose a change to the release process. currently we cut stable branches from 
rc0
. i’d like to propose that we instead cut them from the final 
devX
release of a series. what that would mean concretely is that when we’re ready to cut a stable branch, we do a final 
devX
release rather than 
rc0
. 
rc0
would then be the first patched release from the branch.
➕ 2
💯 1
h
This is an excellent change. Much clearer expectations for users
Related is that we should probably be cutting the 2.12 branch today
👍 1
w
part of the thinking behind the original process was that it’s theoretically possible for the sha from 
main
(the first in the stable branch) to actually become the final release… i.e. that 
rc0
would become the final. but that has never, ever happened, heh.
❗ 1
f
We haven't stabilized 2.11, correct? We should stabilize that first before we start to cut 2.12.
w
the longer 2.12 is open, the longer it will take to stabilize
leaving it open doesn’t do us any favors in that regard… just allows more features to land in 2.12.
f
I’d like us to only be stabilizing one branch at a time. I'd like to see “stable” and “beta” channels like in Rust.
I can write up a proposal. It wouldn't change policy with 2.12 though.
w
@fast-nail-55400: the way that that is achieved is by sticking to a careful 6 week schedule.
if you allow any particular release to run a lot longer than that, it goes a long time without vetting and accumulates lots of untested new features.
as it stands, this is the strategy: https://www.pantsbuild.org/docs/release-strategy … we target cutting stable branches roughly monthly.
we’ve been missing that recently… slipping toward 5 and 6 weeks.
f
I would love to see a 6 week schedule.
w
then you probably want us to cut 2.12.x today, because it’s been about 5.5 weeks 😉
f
Yes we would cut a new beta and release it in 6 weeks. And 2.11 would be the new stable today.
(Having had 6 weeks as beta)
w
maybe that would work, yea. would be interested in the proposal.
(and sorry: it has been about 5* weeks)
@fast-nail-55400: regarding the original post in this thread: any objections?
@hundreds-father-404: there would be enough edits to the docs involved that i don’t think it necessarily makes sense to apply the change for 2.12.x.
h
there would be enough edits to the docs involved that i don’t think it necessarily makes sense to apply the change for 2.12.x.
Sorry, I do not follow. What specifically do you mean?
w
the original proposal in this thread: even if we agree to do it, let’s not do it for 2.12.x
h
Oh. I don't think it's a huge deal to make the change without updating the docs yet? We can call attention to it in the email and Slack announcement. For what it's worth, I've made good progress on 2.11 docs and we can fork 2.12 soon
h
I'm with Tom on this, FWIW
w
i’m open to 1) changing to 6 week cycles, 2) trying to make the transition from focusing on one branch to another more regular. but at a fundamental level: if 
2.11.x
(or any other branch) stills needs fixes, then it still needs fixes. and that means that you either have to slip the schedule, or release something that isn’t ready (and then go on spending time fixing it in 
2.11.1rc0
, etc). rust mostly gets around this by feature flagging everything and disabling features if they’re not baked yet: that’s a related discussion.
👍 1
f
A lot of this will be discipline.
For example, at 2 weeks before cutting the stable release, if a feature is not ready in beta, it should be disabled or removed from beta.
We should preserve the time box element of the release train model over trying to get it to work in that particular version.
w
that’s a choice that can be made, yea. it’s not necessarily one that saves time, per-se. so a tradoff.
h
For example, at 2 weeks before cutting the stable release, if a feature is not ready in beta, it should be disabled or removed from beta.
That is where feature gating would be helpful. I would hate to lose our ability to incrementally work on things. For example, Stu started work on parameterization in 2.10 Maybe what we could do is rename the flag to have 
--experimental
in front. That avoids the problem with our deprecation policy
f
such naming is fine by me
it’s more of setting user expectations correctly
👍 1
h
So, where are we short term? would we be OK with calling today a dev release and still cutting the new branch? Greg is on release calendar so I can do it
f
I’d like to get the JVM dep inf lockfile PRs in before the cut
gotta land the java and scala ones, plus added https://github.com/pantsbuild/pants/pull/15236 for kotlin to hide the lockfile from users
also https://github.com/pantsbuild/pants/pull/15184 for kotlin compiler plugins would be nice to have in as well
h
OK. I can wait to do the release
f
I’m going to give up on the parser lockfile PRs. There is a build failure that if I fixed it by setting the lockfile path to DEFAULT_TOOL_LOCKFILE would prevent us from re-generating those lockfiles. And I don’t want to expose these lockfiles to the user. So those PRs will miss this release.
a
My only input to the OP is that my current algorithm for "should I be releasing (n+1)dev0 or ndev(x+1) is by seeing whether main is currently rc0 or devX, so if we're getting rid of rc0 on main we should make sure we document the new decision algorithm :)
👍 1
h
Slipping the schedule is I think what is being proposed. We would aim to cut a release branch every 4-6 weeks, or as soon as the previous release is stable, whichever is later.
w
good point @average-vr-56795: thanks.
hey folks: it sounds like we’re on track to do 
2.11.0
tomorrow, and to cut the 
2.12.x
branch. does anyone have any objections to using the process from the top of this thread? i.e., having tomorrow’s 
2.12.0.dev4
be the first release of the stable branch? if not, i’ll update the docs for that.
➕ 2
👍 2
💯 1
(it’s possible that to account for DWH’s point about “knowing what to do as releaser”, the precise instructions will be something like “cut the stable branch from the last commit before `2.13.0.dev0`" instead. but the same thing in spirit)
👍 1
hm. yea, DWH’s point makes this a bit trickier. but i think that the answer is probably staring at us from https://peps.python.org/pep-0440/#public-version-identifiers … basically, have our scheme be: 
dev
-> 
a
-> 
rc
. our current 
rc0
would become `a0`… and 
rc0
would follow 
a0
💯 1
we did 
a
and 
b
(alpha and beta) releases in the leadup to 
2.x
for roughly the same reason: because it felt silly to call anything that unstable a “release candidate”, but we still wanted to be on a stable branch.
although having a new release type seems like overhead, i think that it will be easiest from a process and semantics perspective. if we tried to attach the “first release of a stable branch” meaning to a 
dev
release, it has the problem that DWH mentioned (how do we know what the next release on main will be?) but it also doesn’t look like something that (brave) users should help to validate or test (“everyone please test `dev7`").
alright: pulled the trigger on that. https://www.pantsbuild.org/v2.11/docs/release-strategy is updated to mention “Alpha (
a
) releases”
🙌 1
❤️ 1
@fast-nail-55400: are you still thinking of making a proposal here? if not, i might propose a cut down form (targeting 6 weeks, attempting to reduce overlap)
Open in Slack
PreviousNext
Powered by