On 25/01/18 19:08, Matt Caswell wrote: > > > On 25/01/18 11:59, Salz, Rich wrote: >> As long as we have the freedom to release earlier, this looks okay to me. > > I added this sentence to make that freedom crystal clear: > > "This may be amended at any time as the need arises" > > I have taken this proposal and made it into a PR for updating the > release strategy. The PR is here: > > https://github.com/openssl/web/pull/41 > > Please provide any review comments there. Once any reviews seem to have > settled down to a consensus I will propose an OMC vote.
I've had several approvals and no objections on this PR so I think we should go ahead with a vote. My proposed vote text is: "We should update the release strategy as shown in https://github.com/openssl/web/pull/41, commit id 52d9ea8fb" Any objections to the wording before I raise this? Matt > > Matt > > > >> >> On 1/25/18, 6:00 AM, "Matt Caswell" <m...@openssl.org> wrote: >> >> >> >> On 25/01/18 07:39, Richard Levitte wrote: >> > In message <a854cb79-3cab-dea2-e29e-76666d972...@openssl.org> on Wed, >> 24 Jan 2018 20:48:54 +0000, Matt Caswell <m...@openssl.org> said: >> > >> > matt> On 24/01/18 19:12, Salz, Rich wrote: >> > matt> > A monthly release cadence for beta seems too long. I would >> prefer two weeks. And we keep doing that until TLS 1.3 is published. >> > matt> >> > matt> That might be ok. As a technical issue though we can only have a >> maximum >> > matt> of 14 alpha/beta releases (due to the format of >> OPENSSL_VERSION_NUMBER >> > matt> in opensslv.h). If we were to do a release every 2 weeks >> starting on >> > matt> 14th Feb, that would mean the last beta we could possibly do >> would be on >> > matt> 15th August. If there is a risk that the TLSv1.3 publication >> could go >> > matt> beyond that date then we would be stuck. >> > >> > This is the first time, as far as I recall, that we've decided to wait >> > on someone else for our releases, so I'm thinking that we have the >> > freedom to decide how to act if there's a delay, for example to delay >> > our own beta cycle. It shouldn't be too hard to write a kind of >> > "caveat emptor" where we say that "should the TLSv1.3 publication be >> > delayed, we till re-evaluate our plans". >> > >> > (another way to do it is to refuse making a release plan before we >> > receive a clear signal that publication *will* happen and when it >> > will... after all, we *are* putting ourselves in a kind of hostage >> > situation) >> >> Absolutely. As I said in the email that started this thread part of the >> release criteria include: >> >> - TLSv1.3 RFC published >> >> And then I later said: >> >> "If the TLSv1.3 RFC is not published by the time we are ready to >> release,or we haven't made the progress we want on the other release >> criteria then we can add additional betas as we see fit until such time >> as we are ready." >> >> A two week release cadence might look like this: >> >> 13th February 2018, alpha release 1 (pre1) >> 27th February 2018, alpha release 2 (pre2) >> 13th March 2018, beta release 1 (pre3) >> OpenSSL_1_1_1-stable created (feature freeze) >> master becomes basis for 1.1.2 or 1.2.0 (TBD) >> 27th March 2018, beta release 2 (pre4) >> 10th April 2018, beta release 3 (pre5) >> 24th April 2018, beta release 4 (pre6) >> 1st May 2018, release readiness check (new release cycles added if >> required, first possible final release date: 8th May 2018) >> >> Instead of putting the final release date into the plan (which would >> have been 8th May), I have put the the final step as a "release >> readiness check", 1 week after beta4. This puts an explicit opportunity >> for us to see how we are doing against the criteria. If we are ready >> then we could push ahead for an 8th May release, otherwise we extend it >> out as needed. >> >> This plan uses up 6 of our maximum possible 14 pre-releases. If we go >> with this approach and we get to the release readiness check without an >> RFC then we should probably slow down our release cadence at that point. >> >> >> Matt >> _______________________________________________ >> openssl-project mailing list >> openssl-project@openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> >> >> _______________________________________________ >> openssl-project mailing list >> openssl-project@openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project