"release candidate" releases

[Greg Troxel]

meejah <meejah at meejah.ca> writes:

> 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;

I see them as serving the purpose of testing the full trip from a git
branch to a packaging system.  Whether they are called rc, alpha, or
something else is not super important.

My experience is that usually after changes to build system or
dependencies, there are problems in the git->package path, and calls for
testing an rc lead to those being found and fixed.

> 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 you mean that even if a very minor problem is found, affecting only a
minority platform, that you will still do this?  I mean essentially, any
problem that you would have been willing to a apply a post-rc
pre-release fix for?

> 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?

To test packaging, I need to take something that is structurally like a
release tarball and that was created by the very same process, and then
build a package from it.  It doesn't have to have rc in the name.

I don't want to do this every week.   The rc label is how the dev team
says to packagers and anybody else that uses release tarballs "right now
is when I would like you to test, and we aren't going to be making other
than bugfix and maybe doc changes until we release".

As for timing, typically there's a week, maybe more, because many people
who package things aren't paid and thus are squeeizing it in and in my
case I probably look after 50 packages.

> 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.

The real time issue is for people on other than the dev environment to
test, after a change has been made that breaks something, even though of
course you didn't intend to.

If you can set up CI, so that on every commit, there is a

1.16.70.N

pseudorelease made with a release tarball, and that's easy to grab, then
this prretty much turns it into "every commit is an RC", and then you
don't need to make one, but you still need to say "please actually test
now" and refrain from non-bugfix changes.

It would be ok if this had the ID 1.16.70 and unpacked to 1.16.70, and I
would understand that I should not release a package like that.

I do this myself with gpsd, after 'scons dist'.   autoconf/automake make
tihs very easy, and so of course any build system said to be better than
autoconf should too :-)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.tahoe-lafs.org/pipermail/tahoe-dev/attachments/20211102/61cb525c/attachment.asc>