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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
