On Wed, 17 Feb 2021 at 16:15, Ken Giusti <kgiu...@redhat.com> wrote: > > 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. > > > > > A very important point indeed! I think having a schedule "force our hands" > by requiring more emails. Reminders of upcoming milestones to be specific. > And a public schedule makes it fairly difficult to "go dark": having a > milestone come and go without some sort of announcement - even if it's to > acknowledge a slip - isn't something the community should let us get away > with. >
I dont think it makes too much difference overall, the mails can/should be similar overall in both cases and can/do get missed in both cases. > > > > 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. > > > > > To be honest, my personal preference would be to branch unconditionally. I > didn't suggest it simply because I'm under the impression that there'd be > strong resistance to branching. My impression is probably wrong, so I'd > like to propose that a branch is mandatory. Even if it only contains a > change to the version. Ganesh already brought up my dislike of the old branching approach, but its a targeted dislike as I've said. I dont dislike branches in general, just how they were being used. I do dislike branches being created, versions then changed on the branch immediately and tagged, release votes completed very quickly after, and master not having any tags at all (final release or otherwise) but also never having any meaningful diversion from the release branches that did, which is often what happened before. Then to top it off those branches were typically never used again. The version changes and tags could easily have been on master rather than floating alone on a branch, and e.g ignored by git unless you explicitly fetch them or were using the branch. Essentially useless branch, traded off against annoyances of no tags on master. If instead there is actually expected to be a noticeable period of overlapping work with real divergence planned from master before the release (even among bug fixes; not every bug is a blocker...we can do further releases for them, plus others will come up later) then ok, branch had good reason to exist. The tradeoff is still the lack of tags on master, but it at least actually buys something. If there's also actually going to be bug fix releases made from the branch after that, then even better. I'd be very in favour of those, since not everything is a blocker, we can/should do further releases, and I really dont believe we only find important bugs just during the couple days or couple weeks before releases that are spaced much further apart than that..). I've probably also changed my mind somewhat on the idea of tagging master at the point of freeze regardless whether it's actually thought good enough already to change the version number or not, probably is useful even as an indicator to look for other tags from the branch. Could tag it -beta for example regardless whether it was deemed ready for a version change at the point of branching. > > One justification for an unconditional branch is exactly the point you > raise: it makes it much easier to automate CI to simply use the HEAD of the > branch. And that's really the whole point of a stability phase, isn't it - > to ease and encourage the community to start testing early. > > > > > > 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. > > > > > Admittedly, the timescale proposed is more "gut feeling" than actual > science. It's basically a strawman to provide a framework for discussion. > > How about we start with the 10 week/2 week/1 week approach and see how that > works out? > > And let's start by only publishing one release schedule - 1.16.0 - and hold > off planning the 1.17.0 release schedule until after the 1.16.0 feature > freeze. That way we can assess how long the next release's development > window should be based on where we are after the freeze? > > > > > > 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: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > -- > -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
