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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
