Vít Ondruch wrote:
It depends how you maintain your packages. My guess is (and I am
sorry
if I am mistaken) that you don't follow the
https://fedoraproject.org/wiki/Updates_Policy#Philosophy
If you followed this policy, then you would touch the stable branches
just rarely and therefore keeping them fast forwardable would be just
waste of time.
It depends on what, how, and when upstream releases.
If we have different upstream releases in different Fedora releases, then of
course those releases should have different specfiles. But if we are
shipping the same upstream release, I don't see why I should clone the
specfile n times.
There are many possible reasons for shipping the same upstream release
across different Fedora releases:
* There might just not have been a newer upstream release in this time.
* Heck, there might even not be any new upstream releases at all anymore,
which is typical for compatibility libraries such as qt3.
* The newer upstream releases might be bugfix-only releases applicable to
stable Fedora releases just fine. (In other words, there might just not
have been a newer upstream feature release in this time.)
* It can be necessary for security reasons to upgrade to a newer feature
release. (E.g., this is the case for browser packages such as firefox or
chromium. Also for qt5-qtwebengine to some extent, though at least Qt
maintains LTS branches including QtWebEngine security backports these
days.)
* It can be necessary to upgrade a library to a backwards-compatible feature
release because applications are depending on a newer version. (The main
example there is KF5 (KDE Frameworks 5), which does not maintain bugfix
branches at all. But, e.g., Qt also sometimes needs to be upgraded to meet
application demands.)
* There can be other reasons why backporting the newer feature release is a
good idea. (E.g., if it only adds features and does not remove or break
anything, and if it has been thouroughly tested for regressions without
any being found, why would it not be OK to push?)
That said, I am not a fan of the Updates Policy as written because it is
written in the form "do not push new feature releases as updates unless X, Y
or Z", whereas I think it should be "do push new feature releases as updates
unless X', Y' or Z'". Still, I think we all agree that some feature
releases
just need to go out (e.g., because they include security fixes that are
impractical to backport) whereas some definitely must never go out as
updates (e.g., anything that breaks user configuration).
Kevin Kofler