"release candidate" releases
meejah
meejah at meejah.ca
Tue Nov 2 18:51:54 UTC 2021
-----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:
- their meaning is ambiguous;
- there's no clear amount of time/testing/attension required between
an RC and "actual" release;
- they take extra time;
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?
As a reminder, we strive to maintain "master" as "always releasable"
and would like to produce releases more rapidly than has happened
traditionally; removing RC releases is one step on that path.
Thanks,
meejah (for the Tahoe-LAFS team)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEnVor1WiOy4id680/wmAoAxKAaacFAmGBiJEACgkQwmAoAxKA
aafbyAgA0q0ei5xObeN0afp5pa1/bZpq3yRCgKWrPEek19KxkSVz3vACHBCBYcas
GpIWKxXqPqm5Pk5kUon9tMaWJzWw0fa9rvJKrBtFyI4XqTzg5dNuuG9o2HnWqruy
A9DpKSFz+YOYXdAomXPrzGzkeJAOnccywHsIFKP2tnqxUvDNWAwTZPZxAdbI9i9C
OUKCHdOSAxW7IgiqFFJvnyQYrE8xUK8Lk3ZDjH7yvagijgXPEwye/5j+5ccSiDfg
0nCBvuweGnmyTVIJMhyxm09DsGVOKyvpJoCh2MPFcbKKAgXZwQI/YezN0EIUmF3g
jFgBlEfgDRe98DsUm4OHkXaqbu9QVA==
=qSPu
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tahoe-lafs.org/pipermail/tahoe-dev/attachments/20211102/3c2a0be3/attachment-0001.html>
More information about the tahoe-dev
mailing list