I think the whole policy needs rethinking.

The way that we do package maintenance has changed, and it has changed in response to how software is developed. In short: in the past the rate of changes was smaller, and regressions happened quite often. But over the years the standards of software development have improved a lot, along with tooling and automated tests and reporting. There certainly are many projects which don't make use of that and deliver messy releases, but OTOH, there are many projects which do and manage to maintain excellent backwards compatibility at all times. Because of the faster development pace, we as maintainers don't have enough time to backport new features or even non-trivial bug fixes, and effectively we have two options for how to handle stable releases. In the first option, we leave the package unchanged and only do minimal fixes if necessary, and in the second option, we just update to the "latest and greatest". More and more packages do the second, with or without the FESCo permission. And I think that for many packages this is the right answer.

My proposal: remove the package upgrade exception list and replace:

A major version number reflects a more-or-less stable set of features and functionality.
As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience.

with

A major version number reflects a more-or-less stable set of features and functionality.
We want to main stability of the user interface and functionality in stable releases.
Thus updates that would remove or significantly change functionality SHOULD NOT be pushed into stable releases.
Major-version update that maintains a stable user interface or adds features in a way that does not materially affect the user or developer experience with existing features MAY be suitable for stable releases.
Sometimes an update should also be done in a stable branch because this is the only way to provide important bugfixes which are available in a new version and the maintainers cannot or do not want to backport the fixes.
Sometimes an update should be done in stable branches even if it changes or removes functionality in a way that is visible to users. Examples of this include the kernel (… copy some of the existing text here…), browers, e.g. firefox (… copy some of the existing text here…), and other applications which needs to react quickly to changes in the external environment.
Maintainers should make a judgement whether an update should be introduced in stable branches too, taking into account the stability of the interface, potential for regressions, bug fixes, new features, and requirements of other packages. Major-version updates should normally be avoided, but maintainers MAY do them if appropriate.

If folks here think this is something that we should consider, I'd open a thread with this something akin to this proposal of the devel mailing list.

--

(library-only) Rust crates should probably be added to the list of packages exempt from restrictions in the Updates Policy

Let's say I have a library crate which breaks compat, e.g. goes from symver 1.x to 2.0. We wouldn't want this in stable releases, in particular because it's likely to break dependent packages. So I think we should apply a blanket statement based on the implementation language.

I think the whole policy needs rethinking.

I agree, but this ticket is not the right space to do that. Should we open a FESCo ticket for it?

Let's say I have a library crate which breaks compat, e.g. goes from symver 1.x to 2.0. We wouldn't want this in stable releases, in particular because it's likely to break dependent packages. So I think we should apply a blanket statement based on the implementation language.

Sure. Pushing breaking changes should never be intentional, whether on rawhide or on stable branches. When there are SemVer incompatible breaks, I make the necessary adjustments to all packages before pushing them (whether working on rawhide or not), and other Rust packages should (:pray:) do the same, though not everybody seems to understand that ... (:cry:)

Looks like this fell through the cracks. What can I do to move this forward? I don't think rewriting of the entire policy should block documenting a small change that was approved over a year ago.

Please review https://pagure.io/fesco/fesco-docs/pull-request/85.

Thanks, PR looks good to me.