<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> +1 for increasing the dev windows. I think we respected the feature freeze in terms of not making any new PRs after that point. And then reviewed/merged all the necessary PRs before Beta. Yeah, so the Beta release was actually a feature freeze point :) I am for removing feature freeze step and If we decide to do so, my suggestion is to extend the Beta description just to be more explicit, something like this: "All *features* and bug fixes that need to be in the release are complete." Probably not concerns, but just thoughts about some extreme cases for scheduling from beta to beta: * If we'll have a bad Y-1 Beta 1 release, and then a perfect Y Beta 1 release, our Y-1 GA and Y GA could be very close. Is it bad? * And we do not want to cut a Y Beta if Y-1 GA is not out. The probability of such case is low especially if we will increase the dev window. But as an example, there were 6 weeks between 2.10.0 Beta 1 and GA. Tanya <div class="moz-cite-prefix">On 10/14/2016 09:08 PM, Sean Myers wrote: </div> <blockquote cite="mid:0c1b477a-78f4-3992-7114-772d029daef6@redhat.com" type="cite"> <pre wrap="">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]: <a class="moz-txt-link-freetext" href="https://pulp.plan.io/projects/pulp/wiki/Release_Schedule">https://pulp.plan.io/projects/pulp/wiki/Release_Schedule</a> </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Pulp-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </pre> </blockquote> </body> </html>