You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Ken Giusti <kg...@redhat.com> on 2021/03/17 12:09:59 UTC
Re: [dispatch-router] 1.16.0 release schedule
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 <ro...@gmail.com>
wrote:
> On Wed, 17 Feb 2021 at 16:15, Ken Giusti <kg...@redhat.com> wrote:
> >
> > On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <robbie.gemmell@gmail.com
> >
> > wrote:
> >
> > > On Mon, 15 Feb 2021 at 19:41, Ken Giusti <kg...@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.
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: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > --
> > -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: [dispatch-router] 1.16.0 release schedule
Posted by Ganesh Murthy <gm...@redhat.com>.
On Wed, Mar 17, 2021 at 8:16 AM Ken Giusti <kg...@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 <ro...@gmail.com>
> wrote:
>
> > On Wed, 17 Feb 2021 at 16:15, Ken Giusti <kg...@redhat.com> wrote:
> > >
> > > On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <
> robbie.gemmell@gmail.com
> > >
> > > wrote:
> > >
> > > > On Mon, 15 Feb 2021 at 19:41, Ken Giusti <kg...@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.
>
> 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"
>
I prefer this approach very much and it is *mostly* in line with what we
are doing already. Thanks.
>
>
>
> >
> > > 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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> > > --
> > > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> --
> -K
>
Re: [dispatch-router] 1.16.0 release schedule
Posted by Robbie Gemmell <ro...@gmail.com>.
On Wed, 17 Mar 2021 at 12:10, Ken Giusti <kg...@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 <ro...@gmail.com>
> wrote:
>
> > On Wed, 17 Feb 2021 at 16:15, Ken Giusti <kg...@redhat.com> wrote:
> > >
> > > On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <robbie.gemmell@gmail.com
> > >
> > > wrote:
> > >
> > > > On Mon, 15 Feb 2021 at 19:41, Ken Giusti <kg...@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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> > > --
> > > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
> --
> -K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org