[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: schedule for 1.14.0 release

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 22 Apr 2020 13:30:58 +0200

On Wed, Apr 22, 2020 at 1:11 PM Branko Čibej <brane_at_apache.org> wrote:

> On 22.04.2020 13:06, Nathan Hartman wrote:
>
> On Wed, Apr 22, 2020 at 3:13 AM Stefan Sperling <stsp_at_elego.de> wrote:
>
>> The current prospected release date for 1.14 is May 6, which is no longer
>> viable. The official soak period (which starts today) does not allow for
>> a release this soon. We will also need to allocate at least another week
>> to collect new signatures for the final release artifacts once they have
>> become available.
>>
>> So if we stick to the official plan, provided we don't discover any major
>> problems during the soak period, we can prepare 1.14.0 on the 20th of May
>> and probably release on the 27th of May.
>>
>> Is this OK or would anyone prefer to expedite this process (e.g. by
>> shortening the soak period)?
>
>
> This being a LTS .0 release, I think we should stick to the official soak
> as documented, unless someone has a really compelling reason to do
> otherwise.
>
> But perhaps we could try to save the extra week (May 20-27) by parallel
> processing: If no showstoppers are found by May 13th, we could
> optimistically begin testing / signing of the rebranded release artifacts;
> if on May 20th no showstoppers were found in -rc2 and the required
> signatures are collected, then we could release immediately. My only
> concern with this "parallel processing" approach is the risk of confusion
> that could arise if we did discover some major issue in the final week.
>
>
> Agreed.
>

I concur. No compelling reason to shorten the soak. Also, if we would want
to discuss / change the rules regarding the soak, we should do so after
1.14.0 has been released, not during.

I agree that a week of testing is probably not needed. For past .0 releases
most of us that had tested / signed the RC simply signed off quite quickly
with a simple note like "Verified that 1.X.0 is identical to 1.X.0-rcY
modulo version number and harmless changes (docs, ... whatever); and I have
tested an signed 1.X.0-rcY".

> Also, I think we should consider getting the Python 3 fixes for Windows
> into the release. They're only related to bindings and tests, so I don't
> foresee any showstoppers.
>

Yes, I think it would be nice if we could state "complete Py3
compatibility", including the testsuite on Windows. I think the only
problems are with the testsuite BTW (and who on earth even runs the
testsuite on Windows ;-) ...). Oh, and also with "gen-make.py" on Windows
when using "Debug" configuration (still have to bring that one to the list,
sorry).

I don't know the exact rules, but does backporting testsuite fixes cause a
restart of the soak? If we can backport those and include them into the
final 1.14.0 without restarting the soak, that would be ideal. Otherwise ...

> On the other hand, waiting for .1 for that wouldn't be terrible.
>

 ... yes, that's fine too.

-- 
Johan
Received on 2020-04-22 13:31:14 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.