On 29/01/18 11:04, Matt Caswell wrote: > > > 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?
No feedback so I started the vote: topic: We should update the release strategy as shown in https://github.com/openssl/web/pull/41, commit id 52d9ea8fb Proposed by Matt Caswell Public: yes opened: 2018-01-30 closed: yyyy-mm-dd ONE WEEK VOTE I will report back here with the result once the vote is complete. > > 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