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

Reply via email to