https://pantsbuild.org/ logo
Join Slack
Powered by
<@U02TSJJT9DJ> once the UV change is cherry picked...
# development
c
@wide-midnight-78598 once the UV change is cherry picked, are there any release train steps you need a hand with? (The priority of https://github.com/pantsbuild/pants/pull/23221 at DAYJOB is climbing)
w
I held back upcoming releases until the UV merge, as requested by Benjy. Once that's done, I'll start them up again
Looks like it got merged, but failed to cherry pick
🍒 1
Are cherry picks to earlier releases automatically cherry picked into later releases? E.g. if something is cherry picked into 2.31, will it automatically be cherry picked into 2.32?
Also, if we needed a better example of heavy handed release processes, we haven't had anything past 
a0
since 2.25, as far as I can tell. Just a0 to rc seems to be the trajectory.
Actually, @curved-manchester-66006 the docs are a bit ambiguous, if I want to cut an a1, where does that actually happen from? My guess was from the 2.32.x branch, I'd have to bump the version and contrib, then PR that to the 2.32.x branch, then tag that?
c
Are cherry picks to earlier releases automatically cherry picked into later releases? E.g. if something is cherry picked into 2.31, will it automatically be cherry picked into 2.32?
I think empirically that is what I have observed from the bot.
if I want to cut an a1, where does that actually happen from?
I think it has to be from the release branch, since 
main
has diverged at that point? Although I don't recall ever seeing an a1?
w
2.25 and 2.23 This makes me question why alphas exist, and brings me back to my long-running point of simplifying releases overall... But, that's not a today thing, though it should be a soon thing, because the more I work on releases, the less the process makes sense
@curved-manchester-66006 I think this is right? merge from automation/rel into 2.32.x https://github.com/pantsbuild/pants/pull/23325
Note: Made by the Github workflow
This seems to be the norm. PR to the branch, then the branch's CI runs, then we release. Though, I think release is still done via the instructions in the pantsbuild docs by tagging? Basically this. We could have skipped the tag, and just run the workflow itself 🤷
Copy code
name: Release
'on':
  push:
    tags:
    - release_*
  workflow_dispatch:
    inputs:
      ref:
        required: true
        type: string
c
I'm not sure exactly what it looks like in terms of the GitHub Actions/workflows, but I think dropping the double build off of the tag would be fine.
Open in Slack
PreviousNext
Powered by