I believe a failure to upgrade from N-2 to N should not block the N
release. The reason is limited resources, both for tests and for changes
to fix problems. These resources are more valuable applied to the N
release than to something two releases in the past.
If someone wants to test a release-skipping upgrade, fine. Report
problems? Sure. If someone wants to fix these problems, OK; if not, the
policy should be "Upgrade one release at a time. Release-skipping
upgrades may work, but are not guaranteed."
That's exactly what I'm trying to improve here. Either make it a reliable feature,
or warn the users against it very visibly, because this is an operation that can easily
break their system heavily. We don't currently warn the users much, especially the
system-upgrade tool doesn't contain any warnings like that. If we decide we're not
going to support release skipping officially, users should always do a conscious and
informed decision about this and be aware of the risks.
If "upgrade N-2 -> N-1" works, and "upgrade N-1 -> N" works,
N-2 -> N" also works, right? Maybe not, and I think it profligate to
insist we fix a broken two-release upgrade when two single-release
upgrades successfully reach the desired target. Document, do not block.
I may hold a minority opinion, but this seems like another call for QA to
do somebody else's job. Who should decide that release-skip upgrade is a
That would be FESCo. If more people hold your opinion, we should probably file a ticket
and ask them. It's definitely a valid opinion. And it would definitely be easier for
QA. But in this case, I believe the work is worth it, because I personally know many
people who don't want to upgrade twice a year. And offering people a way to upgrade
just once a year (easily, i.e. not going through consecutive upgrades) is something I
consider essential for an operating system.