On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On Mon, 15 Feb 2021 at 19:41, Ken Giusti <kgiu...@redhat.com> 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. > Incomplete features should not make it to the master branch during the development phase. PRs should be raised with the complete feature and if the PRs are approved, they land on the master and hence in the release. Bits and pieces of functionality should not be checked into master branch. > > > > 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 > Like Robbie said, I like the upper timebox on releases but it would be ideal if we could decide what (a list of JIRAs) is going to go into a release ahead of the start of the development phase for an upcoming release and communicate it to this list. That would give users transparency into what they can expect in the next release. If we get the JIRAs assigned to a particular release completed ahead of the feature freeze date, we should immediately do a feature freeze and start the process as you have described earlier instead of having to wait for the feature freeze date of 4/26/2021. As Robbie said, we could keep this list informed of such schedule changes frequently and adjust the reschedule of release based on the feedback we receive. Also, why do we have to create a branch called 1.N.x on the feature freeze date ? Can we create a tag on master say 1.N.x-test and have people test on that tag ? The reason I say this is that there is a good chance that if there are no bugs found during testing, the 1.N.x-test could become the 1.N.x-rc1 tag and eventually turn into 1.N.x. If there were bugs found *and* if there are commits on master that we do not want to include in the release, then we can go ahead and create the 1.N.x branch from the 1.N.x-test tag. Later on when the release is done, we can delete the 1.N.x-test tag. Earlier, we were always creating these release branches when we did releases but Robbie suggested that *at times*, creation of a release branch might not be necessary. From that time, we have been creating rc1 and release tags directly off of master and it has worked out well. > > > 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: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
