It would be better for user experience if fedup without parameters would default to --network (installed_version + 1) ie. if I'm on f19, fedup should default to fedup --network 20 To prevent accidental runs of people who ran fedup without parameters, it could ask the user, something along the lines of "Do you want to upgrade to Fedora 20? [y/n]"
...and what if you're on F18? Should it default to F19 or F20? ...and how would we automatically determine whether F20 is "available" or not?
If you're on F18 it should default to F19 because skipping a version when upgrading was never supported in previous tools and harder to debug. To determine if F20 is available or not, we could use a releases.txt file hosted as a plain text file in fedoraproject.org like PreUpgrade used to have (I have no idea if that file still exist, but bringing it back should not be a problem).
(In reply to Elad Alfassa from comment #2) > If you're on F18 it should default to F19 because skipping a version when > upgrading was never supported in previous tools and harder to debug. Supporting upgrades to N+2 is a huge timesaver for the end user, and none of the problems so far have been any harder to debug than N+1 upgrades. I also don't feel comfortable setting policy on this unilaterally. Ask FESCo or something? > To determine if F20 is available or not, we could use a releases.txt file > hosted as a plain text file in fedoraproject.org like PreUpgrade used to > have (I have no idea if that file still exist, but bringing it back should > not be a problem). Sounds good. Let me know when that file exists and rel-eng has agreed on SOP for updating it as part of the release, and when there's some defined policy for whether we should prefer "upgrade to newest" or "only upgrade to N+1". Once we have those, fedup can support the requested behavior.
I'll file a FESCO ticket with those two questions soon. it seems the file still exists, but is no longer updated https://mirrors.fedoraproject.org/releases.txt
IMHO the best way to get this info is via pkgdb. See: https://admin.fedoraproject.org/pkgdb/api/ and in particular: https://admin.fedoraproject.org/pkgdb/api/collections/ If something is "active" it's an option, if something is "under development" it's a branched or rawhide.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Reassigning to fedup's replacement.
(In reply to Kevin Fenzi from comment #5) > https://admin.fedoraproject.org/pkgdb/api/collections/ This should work nicely. So now we just need the ability to override releasever from the plugin (#1212341) As a cherry on top, we could support +1 and +2 as the version arguments.
POC implementation of fetching collections: https://github.com/keszybz/dnf-plugin-fedup/commit/15be0d09e4abf3f6c60a8d392e4df441519fff49.
We will consider this feature.
As you can see on this page https://fedoraproject.org/wiki/DNF_system_upgrade, system upgrade plugin can change releasever. As releasever you can add N+1 or N+2 or anything what you wish, but transaction success doesn't depend on plugin it self, but on installed packages and how new released repository is prepared for this upgrade. The question is also availability of gpg keys in old packages in old released. I am really sorry but I don't see here any issue of DNF or plugin. If you will feel, that I overlooked something, please don't hesitate to reopen the bug report with additional information or experience.