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 <[email protected]> wrote: > On Wed, 17 Feb 2021 at 16:15, Ken Giusti <[email protected]> wrote: > > > > On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <[email protected] > > > > wrote: > > > > > 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. > > > > > > > > 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. 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" > > > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > -K > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K
