Formalize policy for releases #11702
Replies: 3 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
-
I'd like to propose that major/minor releases happen on Wednesdays, right after the meeting. That way the attendees can be polled for 👍 / 👎 to go ahead. Given that, I would propose initial RC1s happen on the previous Thursday. Here is what I would point out though: in order for there to be confidence that "RC1" does in fact have a good chance of not needing more work, testing for downstream projects needs to happen before that point. i.e. the goal needs to be that an "RC1" is "ready to release" not that is is "ready to test". For point releases I would be ok with (weekday) 48hrs from RC to release. Now that we can actually issue point releases on old branches, I tool a look back an we have been reasonably conservative with both size and content thus far.
Sure but notify how? My only real concern/requirement is that it be something we can move towards automating. (emails, discourse posts, slack posts, issue creation on specified trackers, whatever)
Yes, and I think we should consider making this a rotating responsibility, if only to reduce the bus-factor |
Beta Was this translation helpful? Give feedback.
-
Hmm. To me, that's what an "RC" already is: ready to test manually. I.e., all automated tests are passing, all features are in, basic manual tests pass, could be ready to go; now let's all test and find out if it really is! As an external project maintainer, I need to know when such a point has been reached in Bokeh so that it's appropriate to run through a manual checklist or even that it's worth investigating failures on CI that we could otherwise think are just due to things in progress. An alpha release isn't one that I'd think is worth that effort; sometimes in my projects we have a dozen or more alpha releases for a given public release. But if an RC appears, we should get into gear and start seeing what work we have. In any case, if you don't want to call that stage RC, would you call it "gamma" or some other level that indicates not quite RC but ready for external testers? If so, that's fine; I'm not wedded to those particular characters... |
Beta Was this translation helpful? Give feedback.
-
In the context of the Bokeh 2.4 release we started discussing what the policy around release candidates, feature freezes, etc. should be. Specifically in the past we have had a policy of declaring a feature freeze one week ahead of release which would be accompanied by an RC. Subsequently we would only merge bug/regression fixes followed by further release candidates. This policy has never really been formalized and so it was only partially adhered to. Therefore I wanted to start a discussion to work out a formal policy.
There's three distinct groups of stakeholders with different needs affected here:
Whatever policy we come up with should give both users and downstream developers sufficient lead time to test an RC and report any issues. This should also be accompanied by a formal process for publicly announcing RC releases and notifying relevant stakeholders.
Some questions we should answer:
Beta Was this translation helpful? Give feedback.
All reactions