hi,
anonym wrote (18 Mar 2014 19:47:15 GMT) :
> This was copy-pasted from the example in the release process docs, and I
> only added `--previous-version 0.22`. However, I suppose I should've
> also one it for 0.22~rc1 and (the incorrectly named?) 0.22-rc2?
I think so, yes.
Please fix the release doc if "A few (say, 2 or 3) older versions must
be passed with `--previous-version`, so that users who skipped
a release or two are directly informed of the new one" is not
clear enough.
> The people that tested the incremental upgrade paths for the 0.23
> release wondered if removing the 0.22 -> 0.22.1 -> 0.23 incremental
> upgrade path is intentional.
It is.
> It will be available for those that have done the 0.22.1 incremental
> upgrade before 0.23 goes live, but not to those that do it
> afterwards, which they found weird.
Once 0.23 is out, then 0.22.1 is unsupported, and upgrading to 0.22.1
is unsupported as well. Makes sense to me, in order to avoid
supporting too many combinations at the same time :)
> Some clarification (and, possibly, discussion) for when to EOL
> incremental upgrade paths seems in place. In particular, and somewhat
> more urgently, what is the correct thing for the imminent 0.23 release?
0.22 did not have incremental upgrades enabled by default, so in the
case at hand, we don't care much.
In general: the information that an upgrade-description file conveys
is "what version you should be running right now", and "how you can
directly upgrade to a sane version". I think that full upgrade is the
only thing we can support to users who skipped a recommended upgrade.
Anything else will cause more work, and I can't see the benefit of it.
> Also, what about the alpha channel? We currently still have e.g.
> the 0.22.1_to_0.23~rc1 incremental upgrade path; the current process
> doesn't clean them up.
In the current state of things, the alpha channel is for one-shot
testing purposes only, and not supported at all outside of the cases
when we specifically document to use it. If you care much about it,
feel free to remove these obsolete upgrade paths. Else, no harm done
by keeping it around.
> Related to this is what to do with "orphaned" IUKs that no longer is
> part of any described upgrade path. I suppose a step for cleaning up
> orphaned IUKs from the rsync server should be added to after "Go wild!"
> -> "Push".
Nice catch. Please file a ticket if you're not doing it right now.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
