On Wed, 17 Mar 2021 at 12:10, Ken Giusti <kgiu...@redhat.com> wrote: > > I apologize for my belated response - I've been on a mini-sabbatical for > the last three weeks and am now playing email catch-up... > > On Wed, Feb 17, 2021 at 2:17 PM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > 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. > > > > > Hi Robbie - correct me if I'm misinterpreting your response. It sounds like > you're describing a "lazy" branching model: branch off of mainline only if > additional commits need to be made to address release-blocker bugs found > after the freeze. >
Thats essentially what I suggested long ago and happens just now, yes..though not with the beta tag, just going straight with -rc1 tag when deemed ready for it and opening a vote. It would perhaps need tweaked if the intent is to have a -beta tag and period where master/main isnt primarily still just the target of the next release. > For example: > > At the start of the release freeze drop a tag on the HEAD of the mainline > to mark the freeze point. Say "1.16-beta" or whatever. > > If/when a release blocker bug is found and fixed then create a branch from > 1.16-beta and cherry-pick/merge/whatever the fix onto the branch. > Subsequent release blocker bug fixes would also land on that branch, of > course. > > The *rc tag(s), 1.16.0 tags would then either be on the branch (if created) > or - since no extra commits where added to the release - the same commit as > "1.16-beta" > > That would work yep, except you couldn't use the beta tag commit directly for the rc1 tag, unless the beta tag was versioned non-snapshot (at which point master/main would need changed back to a snapshot for further change). If it wasnt then you would always have to reversion and place a new tag, either still on master if incorporating all of the (possibly zero) code changes there since the beta tag, or on a branch if picking and choosing only select changes. If on the other hand it was to be set as a non-snapshot then you might as well go with -rc1 immediately and open a long vote; they dont need to close after 3 days. Note you wouldnt necessarily get a named floating target (other than master/main) for use with pre-release testing in that case, which you initially seemed to be interested in. Such testing would have to remain targeted only at master/main, or the static tag(s), until such time there was ever an actual branch. > > > > > > 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 > > > > > > -- > -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
