On Tue, 2 Nov 2021, at 13:52, Greg Troxel wrote: > > meejah <mee...@meejah.ca> writes: >
Great, thanks for the followup! > > 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? Yes, any problems found for any supported platform would receive a prompt fix and followup release (e.g. 1.17.1) just the same as if a problem was found with "rc0" and a "rc1" followup was required. > 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". This wouldn't be every week. We currently do "some" releases per year, and we'd like that to be a little more frequent (but almost certainly _not_ as frequent as "every week"). Currently, we basically say "here is 1.17.0-rc0, please report problems" and then some ill-defined amount of time later we "release" 1.17.0. The proposed change is to just say "here is 1.17.0, please report problems". I suppose in extreme circumstances it may be the case that a release would have to be pulled entirely (e.g. if there was some larger problem discovered that couldn't be fixed promptly). [...] > 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. I do personally like this idea a lot -- that is, essentially, to replace "RC" releases with an "always available" latest release from master. I mean, we could even name them as such so that e.g. the first commit to master after 1.17.0 might produce a "1.18.0-rc0" or so (but maybe "1.18.0-alpha1" or so makes sense). The labelling isn't _that_ important, so long as downstream systems like PyPI or pip/poetry/etc aren't confused and believe there's a newer "actual" release out. This could also, in the immediate term, serve to test out further release automation -- especially if they aren't signed (or are signed by a "CI-only automated release key" that people can choose to trust less if appropriate). Thanks, meejah
_______________________________________________ tahoe-dev mailing list tahoe-dev@lists.tahoe-lafs.org https://lists.tahoe-lafs.org/mailman/listinfo/tahoe-dev
