On Mon, 15 Feb 2021 at 19:41, Ken Giusti <[email protected]> wrote: > > Folks, > > Now that Qpid Dispatch Router 1.15.0 has been released it's time to move on > to 1.16 development. > > I'd like to take this opportunity to propose that the project adopt a > time-based release cycle for minor releases, starting with 1.16.0. > > Previous releases have been driven primarily by feature completion rather > than by a pre-established public schedule. While this approach is great > for developers it doesn't help the rest of the community plan for testing > and deployment of the new release. > > As it stands now the only formal notification provided to the community is > when a release candidate has been cut and the vote is announced. >
Nothing requires that of course, it's just what's been happening. Heads up and progress mails could easily have been sent, and could be used to provide similar notice whether working on a specific time schedule or to specific feature completions going forward. Arguably even with time scheduled releases the desired effect discussed still won't fully be realised without such mails. > Going forward I'd like to propose a quarterly (13 week) minor release > schedule which includes a feature freeze milestone and stabilization > period. The proposed 13 week release timetable would consist of the > following: > > Development phase: 10 weeks. > > In this phase the master branch is open for all development - features, bug > fixes, test development, etc. > > Feature freeze and start of stabilization phase: 2 weeks. > > After the 10 week development phase a tag is dropped at the head of > master. This tag is the root of the 1.N.x release branch. Development for > the next minor release continues on master. > I think such a tag would need to be named to make clear what it represents and that they should typically not be used, as beyond the very point they are created it mainly only seems useful as a delimiter of sorts for master. If the idea is for folks to test upcoming bits before their release, it would seem they should essentially always be using the head of the branch for any pre-release testing as anything else is likely already stale. > The goal of this phase is to allow time for the community to start testing > the upcoming release and report issues. It gives developers time to land > bug fixes without the pressure of holding up the release vote. > > To keep the release branch as stable as possible only bug fixes are > allowed. Fixes destined for the release branch should be made on master if > applicable and cherry picked onto the release branch once they've proved > stable. > > Any features not completed when the freeze occurs will be rescheduled to > the next minor release. This may require removing or disabling incomplete > features on the release branch - specifics will be determined on a case by > case basis. > > Release Phase: 1 week. > > At the end of the stabilization phase a release candidate is made from the > tip of the release branch and the vote is called. Failure to pass the vote > may cause this phase to slip, but hopefully the stabilization phase will > make this unlikely. > > Once the release is done, fix releases (e.g. 1.16.1, 1.16.2) are made from > the release branch as needed until the next minor release becomes available. > > Thoughts, opinions? > To rephrase, this essentially seems to be a 10-week feature release frequency proposal, with 3 further weeks where two streams overlap their different stages, giving roughly 5 feature releases a year. That is much the same overall to the rate of the recent years, but just with the aim of fixed 10 week cadence vs more variable spread of 1 to 4 months. Trying to ensure releases actually occur by having an upper time box seems good. There often feels like there aren't enough releases, particularly around the times of those longer cycles which this would specifically prevent. Though as above it wouldn't really look to change things much in terms of overall releases, unless there actually typically are also bug fix releases being done which historically there has not. In some ways it seems like it could also make things a little worse, with any feature just missing one release freeze then needing to wait a certain 10 weeks extra to become available, rather than previously perhaps getting their own release however soon afterwards was appropriate. Admittedly that's probably not what typically happened with many of the previous Dispatch cases though, other than maybe the rare ~1month release cycles, with it more likely the not-quite-ready feature instead just extended the current release cycle somewhat so as to avoid holding that features delivery (while holding all the rest), or perhaps often as much just to avoid the effort of having to do another release mainly for it. I would expect very similar situations to continue if the chosen time window is too large, with not-really-ready stuff optimistically landing before freezes in expectation of polishing up in the 2 week stabilization window and avoiding waiting for another release. Obviously that's ok if there is success, and note was also made that things could alternatively be disabled/removed before the release, but I think it's something to consider that probably won't change all that much at all from previous, and with the known 10 week penalty it may even get slightly worse. That all also expects that any potential fix-releases definitely aren't allowed to include even small effectively-feature changes as suggested of course, which will often seem tempting to creep them into if the time-window for minor releases is too slow. I'd likely go with a slightly smaller time window personally, or at least be open to using a different cycle for additional releases when seems appropriate such a particularly useful feature being known/expected to be just miss one of the slower regularly scheduled slots. > Applying this model to the upcoming 1.16.0 release: > > Start of Development Phase: 2/15/2021 > Start of Feature Freeze: 4/26/2021 > RC Release: 5/10/2021 > > 1.17.0: > Start of Development Phase: 4/26/2021 > Start of Feature Freeze: 7/05/2021 > RC Release: 7/19/2021 > > > > -- > -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
