"release candidate" releases

[Jeffrey Walton]

On Tue, Nov 2, 2021 at 2:52 PM meejah <meejah at meejah.ca> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello Fellow LAFS-ians,
>
> Today in our governance meeting we discussed "release candidate" releases.
> We would like to get rid of them for a few reasons:
> ...
>
> We don't believe this makes a huge practical difference: if a problem
> with a release is discovered we will work to quickly produce a
> follow-up. This is true if the problem is in "rc2" (and we produce
> "rc3") or if the problem is in 1.17.0 (and we produce 1.17.1).
>
> Do any of our downstream consumers have any issues with this plan?
> What use-cases do the existing "rcN" releases answer for you if so?

I think it's a good idea if that's the direction you want to go in.

In a few of the projects I help maintain we stopped doing the RC
thing. The biggest reasons were:

* there is no practical difference between "please test master" and
"please test this tarball"
* we have to archive the RC tarballs for posterity since they are a release, too

We also found it does not matter how much time you wait for testing of
master or a tarball. Folks who help with testing are going to do it
within a week or so. Everyone else is going to wait for the release
and then upgrade. You will get a few bug reports after you release
from the latent testers who simply upgrade. So we plan on a
dot-release 30 days from the given release because we know we will get
a few bug reports after the given release.

Jeff