[dispatch-router] 1.16.0 release schedule

[Ken Giusti <kg...@redhat.com>]

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.

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.

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?

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

Re: [dispatch-router] 1.16.0 release schedule

[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

[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

Re: [dispatch-router] 1.16.0 release schedule

[Ken Giusti <kg...@redhat.com>]

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

[Robbie Gemmell <ro...@gmail.com>]

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 <ro...@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.

>
> 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

Re: [dispatch-router] 1.16.0 release schedule

[Ken Giusti <kg...@redhat.com>]

On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <ro...@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.


> > 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.

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

Re: [dispatch-router] 1.16.0 release schedule

[Robbie Gemmell <ro...@gmail.com>]

On Tue, 16 Feb 2021 at 14:49, Ganesh Murthy <gm...@redhat.com> wrote:
>
> On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <ro...@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.
> >
> > > 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.
>

It's not uncommon for things to be considered ready, right up until it
later turns out it wasn't :)

Somewhat separately, it seems likely some changes are likely to be too
big to fit in a specific release. Say, the ones that just took several
months before 1.15.0. However perhaps they can be composed from
several sub-parts that can be landed independently over time, rather
than having several months of change sitting on feature branches and
requiring a big bang land and/or repeated rebasing.

> > >
> > > 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.

Mainly I was suggesting that, if things are time-based normally but at
the point one release is being frozen and work beginning on the next,
if something particularly useful missed that gate but would be ready
soon, then a feature-based followup could always be adopted instead
for the next release rather than the typical 10 weeks wait (actually
13 weeks at that point really) for the time-based followup.

>
> 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.

A 1.N.x-test tag cant be 1.N.x-rc1 if it still has the wrong version.
If it's considered good enough already to give it the release version
to tag it, you should probably just proceed to the release process.

If the freeze point is truly done on a time basis it seems likely bugs
can always be found. If you can't find a new one, perhaps even hit up
JIRA for old ones that are yet to be addressed ;)

People can easily test out  particular commits or branches (which can
be created but needn't automatically be used for the eventual release
in the end, and/or can be replaced later), I wouldnt say they dont
need tags, particularly temporary ones. From experience many dont
though, choosing to wait [nearly] until the vote opens, and perhaps
even later than that if they rather expect an rc-<foo> to appear.

> 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.

I did suggest that, because the process adopted at the time almost
always precluded anything else happening, meaning that the release
branch had been created and used for the release, while master sat
there without any tags but exactly matching code content, and the .x
branch was never used again due to the general absence of bugfix
releases. In cases like that, I much prefer releasing off master so
the release tags are there. If this process aims to go differently and
essentially aims to branch earlier, with actual feature changes
happening on master concurrently with the 3 week release prep, then it
seems the initial release will need to be off the branch.

If however the expectation is things would pan out essentially as has
typically happened before then I would once more suggest ditching the
branch. As above though, you can always create a branch initially and
decide to still release off master if it remains doable at the
appropriate point (perhaps only needing a commit to wind the version
to desired value). Branches can be deleted or replaced too. Or named
something besides 1.N.x until after a release actually happens.

>
> >
> > > 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
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [dispatch-router] 1.16.0 release schedule

[Ganesh Murthy <gm...@redhat.com>]

On Tue, Feb 16, 2021 at 8:52 AM Robbie Gemmell <ro...@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.
>
> > 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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Re: [dispatch-router] 1.16.0 release schedule

[Robbie Gemmell <ro...@gmail.com>]

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.

> 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.
>
> 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
>
> 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