short reflection on the topic of release cadence and process. Looking at the changes going into the 2.16.0 rcs, and the time it is taking to stabilize I wonder if we had moved to stable sooner, some of those would’ve instead gone into 2.16.1, 2.16.2 etc.. Not suggesting to go too fast with open or many unknowns, but still allowing some things to slip into patch releases to allow a more predictable timeframe for stabilization as now each time there are some minor fixes to the current rc, it’ll force another rc before going stable pushing it away one week at a time. It’s a balancing act and no one answer will always be the right one, but maybe worth considering from time to time.

I feel like I'm to blame here, partially. historically I've waited until the first RC to try out Pants at my work repo. That's when the bugs started flowing in. And each bug meant waiting for the next RC, and then finding the next one. Maybe our testing isn't as good as it should be? Or maybe we need stricter reviews? Certainly testing newer Pants sooner would also assist.

yea, I’m not looking for blame here and certainly finding bugs and fixing them before releasing a stable version is preferable (rather we find the bugs than the wider user base). Finding many bugs during rc is a bit disconcerting though..

I think it boils down to testing and release cadence. We don't test soon enough (because technically as an organization, we don't do any testing that isn't pytest testing. We rely on early adopters). Honestly though each bug was in different backends. My thought is that we should decouple pants package from the backends so we CAN release those more often and push bugfixes immediately

If doing so tightens up the release process so that for example 2.16.1 and 2.16.2 can roll out quickly too, then I think it worthwhile to explore yeah.

totally agree with releasing backends separately would help this scenario.

Would we need more releasers if we decoupled the backends?

No. I'm determined to work on making releases as automatic as possible, so I'd call that a prereq

not contributed to it (yet) but I’m also on board with 1) automation, then 2) the rest

I wonder if we (maintainers who have work/external pants repos) could try dev and alpha releases as they come out, to try to catch bugs earlier? This isn't particularly scalable and is attacking the problem from a different angle, but I feel there has to be some sort of human oversight to update to the latest features and identify "this weird behaviour/output/slowdown is a bug", in addition to obvious failures. Similar to Josh, I've mostly just been validating the rcs (unless I'm validating a particular feature I implemented or reviewed), but I'll go try out 2.17 and 2.18 now!