#23348 Streamlining the Pants release process New discussion created by sureshjoshi Context: https://www.pantsbuild.org/stable/docs/contributions/releases/release-strategy During the course of automating our release process via GitHub Actions, it's clear to me that we have some steps that don't generate much user value, burn CI time for functionally no reason (re-running CI for no actual changes), and require maintainer babysitting. This babysitting problem has been made all the more fun with Github's notable downtimes. At any given time, we have: • 2-3 "stable" releases with some cherry-picked fixes • one likely about to become stable •

dev

snapshots on

main

(roughly, but not exactly weekly) The process of becoming "stable" is to go from 2.32.0.dev0 -> 2.32.0.devN -> 2.32.0a0 -> 2.32.0aN -> 2.32.0rc0 -> 2.32.0rcN -> 2.32.0 (stable) -> 2.32.1rc0 -> 2.32.1rcN -> 2.32.1 (stable) Often the N is 3-5 on

dev

, 1 in

a

, 1-2 in

rc

. The intention of the

a

and

rc

are for Pants users to test out pre-release versions of Pants for stability in their repos with any particular new features, to raise the flag if anything crazy happens, so we can hold off on creating a stable release. That's worked better in theory than in practice, as many users tend to not update until there is a stable release - thus, chicken and egg. In practice, the 3ish stable, supported versions lasts about 3-6 months, as a newer release will have likely taken over by then. --- In my experience as a Pants user, service provider, maintainer, and Slack watcher - I've seen 3 main ways users handle Pants (or just any library/tool in general) versioning: • Bleeding edge • Latest stable (when they find a feature they like, or remember to update) • Archaic version We've had a recent example of a user needing to drop back 1 stable release due to two conflicting updates, so that's a data point as well. The holding back on an update usually happens due to a deprecation or breaking change, which are somewhat less frequent now, but still happen and we'd still keep some minimum number of cycles before removing a deprecation. --- My proposal is to streamline this workflow as follows: • Scheduled weekly dev releases (cron) - not much change here • Single stable release branch • No more alpha releases •

rc

only until the stable

.0

release • Regular patch updates afterwards, without in-between

rc

• Released on a weekly schedule, or ad-hoc, as needed Note: There will be some more formality to this re: versioning, breaking changes, durations, etc after there is feedback on the concept of the idea. pantsbuild/pants