I think the current Y Release Cadence has proven to be untenable. Here's a summary of what I think about it based on our experience: * Branching at the first build (beta 1 release) works very well, so we should keep doing that. * 6-week GA-to-GA dev windows are too small, so we should increase this to 9 weeks (maybe more) * Our betas seem to always catch a few blockers, so the timeline always slips between beta and RC, and might slip again between RC and GA. This is completely normal, and is in fact why we have Beta and RC stages, so this uncertainty should be built into the process. * I don't know that we ever really respected the feature freeze; it seemed to me like the knowledge that we were cutting a beta in a week was "good enough", and there's no need to formally freeze development. Our three-week sprint cycles also do a good job of effectively feature-freezing every three weeks. * "Resetting the clock" after each beta, and especially after each release candidate, doesn't seem to add stability. Instead, it seems to add frustration in the form of release delays. The decision to advance from Beta to RC and RC to GA should be handled per-release, with the only strictly enforced time restriction being that a minimum of one week should pass before advancing to the next phase is allowed.
With those points in mind, the proposed changes are to release the first beta
in a time-based way,
9 weeks after the release date of the first beta of the previous Y release.
Once a beta is released,
no release timelines are guaranteed for the progression from beta to RC to GA
beyond reasonable
minimums (currently 1 week minimum testing time for a beta, and 1 week minimum
testing time for RC).
Scheduling from beta to beta isolates the release process from the normal
pre-release rebuilding
delays that happen as a result of fixing blocking issues, while still giving
the release schedule
predictability so folks can do reasonable planning around our release dates.
With all that preamble, here's my proposed "Y" release schedule:
---
The Y release cycle begins on the day of the previous *Beta* Y release.
* week 0: (Y-1 Release) Previous Y release cycle begins with a Beta Release
* week 9: (Y Release) Y release cycle begins with a Beta Release
** dev branch created for this Y Release
** build system adapted to build from dev branch
** master branch now tracks development for next Y release
** beta is built from dev branch
* week 9+1?: Y release advances through Beta phase to RC as phase conditions
are met, with
a minimum time in Beta of one week. Release schedule is no longer
time-based.
* week 9+2?: Y release advances through RC phase to GA as phase conditions are
met, with
a minimum time in RC of one week.
---
The phase conditions mentioned in this schedule are listed on the linked wiki
page already,
but should be more clearly defined. Along with this proposed schedule, here are
my proposed
definitions for those terms:
Beta: All bug fixes that need to be in the release are complete. Dev believes
the release is ready.
For Y releases, verification of the new functionality begins.
Release Candidate (RC): Verification of new functionality is completed. No new
bug fixes accepted
after this point except fixes for regressions, upgrade
failures, or security.
There are no release candidates for Z releases.
Generally Available (GA): Unchanged.
Dev branch: Unchanged.
Feature Freeze: This definition should go away if feature freeze is removed
from our "Y" release schedule.
If we keep the feature freeze step in, this definition can
remain unchanged.
This schedule is less structured that the previous iteration, but I think it
more accurately
reflects how our releases actually go.
The 2.10.0 beta was first released August 4, which would mean that under this
schedule we would
have begun the 2.11 release process last week. That feels about right to me, if
we were staying
on a strict time-based release cadence for 2.y, but going back to a 12-week
(quarterly-ish)
schedule would probably also be reasonable.
For reference, here's the current "Y" release cadence posted in the project
wiki[0]:
---
The Y release cycle begins on the day of the previous GA Y release.
* week 0: (Y-1) Previous Y Generally Available Release
* week 3: Feature Freeze
* week 4: Beta Y release
** dev branch created for this Y Release
** build system adapted to build from dev branch
** master branch now tracks development for next Y release
** beta is built from dev branch
* week 5: Y Release Candidate
* week 6: Generally Available Y Release
---
More words here because this email doesn't have enough words...
[0]: https://pulp.plan.io/projects/pulp/wiki/Release_Schedule
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
