#1534 Approve skip-release upgrading as an officially supported upgrade method
Closed None Opened 3 years ago by kparal.

= phenomenon =
In the last 2 months we have discussed the idea of officially supporting skip-release system upgrades, i.e. upgrading the system from FN to FN+2 directly. The major parties involved in this all agreed. I'd like FESCo to officially approve this as a supported feature of Fedora.

= background analysis =
Skip-release upgrading always mostly worked and many many users used it, but it was never officially supported, recommended, tested or blocked on. Our release lifecycle (3 releases overlapping 1 month in support, to allow users to upgrade just once a year) fits exactly this use case of skip-release upgrading and many users understand it as such, and we have never discouraged them from it (too visibly). Yet when an important bug is found, QA has no means to delay the release and ensure the problem is fixed in time.

I have proposed to fix this disconnection between what we do and how (many) users understand our lifecycle and upgrade process by officially supporting skip-release upgrades. The proposal and most of the discussion can be found in the test list:

The QA team has provided their support for this, as well as Will Woods from dnf-plugin-system-upgrade and Richard Hughes and Kalev Lember from gnome-software + packagekit (CCing them here).

From packaging standpoint, the packaging guidelines should already cover the most important cases according to this discussion:

Our QA tools are prepared for this (we have new testcases ready, OpenQA should already test skip-release upgrades), we just need to modify our current release criterion.

As this is a change that touches many different teams and areas, I'd like FESCo to approve this officially. Thank you.

= implementation recommendation =

There were ideas that skip-release upgrading policy could be mentioned in https://fedoraproject.org/wiki/Updates_Policy (i.e. saying that we do support this). However, that document mentions only updates, not system upgrades (not even the standard one), so I can't say whether it is a good fit for that document, or somewhere else, or whether it's not needed to write it down at all (it will be in the release criteria, if approved).

Could you post this on devel list for further discussion in the community? I may have missed it, but I don't recall seeing it posted there.

Ah, I did in fact miss it. Disregard my previous request. Though I am slightly concerned it got very little feedback on the devel list, that isn't your problem.

For the record, the devel list discussion is here:

Unfortunately I received just 2 replies, from Richard and Kalev, and Richard's does not show up in the archive for some reason, but is quoted here:

I can try to revive the devel list discussion and ask people for feedback with a bit more urgency, if you prefer.

FTR I'm very in favor of this. I just didn't say anything because a) it's not me the work falls on, and b) no one seemed opposed, so... not much else to say. :)

We'll discuss this in the meeting tomorrow at 17:00 UTC on #fedora-meeting

As all stakeholders agree, +1 to the proposal but explicitly from N to N+2 as this will be tested and supported. I consider this goes in the right direction.
This is not a blanck cheque for untested scenarios (e.g. N to N+3).

For the record, we (QA) had no intention to 'support' anything beyond two releases, and I don't think we ever would so long as the maintenance cycle reminds 'two releases plus one month', as that makes it simply non-viable to support anything over two releases (as by the time N+3 stabilizes, we can't ship updates to fix problems with upgrades from N any more because it's EOL).

AGREED: Approve skip-release upgrading as an officially supported upgrade method (+1:8,0:1,-1:0) (kalev, 17:19:46)


Login to comment on this ticket.