I'd like to suggest specific updates (I'd feel more like I was
contributing to a productive conversation and less like I'm merely
complaining), but I'm a little unclear FESCo's point of view. I'll do my
best.
Given the discussion so far, I feel like Fedora effectively allows at
least leaf nodes to update without significant oversight, and I wonder
if it would be useful to reflect that distinction more fully in the
philosophy statement. I am unclear on the general sentiment toward
updates of packages that are not leaf nodes, and I tend to think that
it's valuable to maintain minor-version stability (feature stability) on
those packages even if leaf nodes are expected to maintain only
major-version stability (compatible-interface stability). If that's an
acceptable point of view, perhaps replace the fourth sentence of the
first paragraph with:
Updates to shared dependencies should aim to only fix bugs, and not
introduce features. Updates to "leaf" nodes may introduce new
features, but only when those features would not be disruptive to
the user or developer experience.
It might also be helpful to express a preference for either stability or
updates when the upstream vendor is actively supporting two stable
releases of a leaf node.
In the third paragraph, the phrase "ABI changes in general are very
strongly discouraged" could be prefixed with "Any" or "Incompatible" in
order to further clarify whether Fedora releases are supposed to
maintain Major-version or Minor-version stability in dependency packages.
The Exceptions section says "If your package does not fit in one of the
classes below..." is confusing, but probably only because the exceptions
list is disorganized. It starts with specific packages that have
exceptions (the kernel, KDE, and other packages), and then "Security
fixes" -- which looks like a class of packages with an exception, except
that it requires a FESCo ticket as packages without an exception do (and
then lists the kernel, again), and finishes with two classes of packages
with an exception to the policy. Here, I'd suggest some minor
reorganization: classes of packages that have exceptions generally, and
then specific packages with exceptions. Security fixes seems like it
belongs at the end, possibly noting that security fixes do not have an
exception from the stable release policy, but approval of rebase updates
is fast-tracked. Or, if they do have an exception because of the nature
of the update, then generally reword all of this. Possibly to note that
a ticket is required in order to organize rebuilding any related
packages that require it, if packagers are not required to wait for
FESCo approval. (And, remove the duplicate reference to the policy
exception for the kernel)
The first Example describes a Firefox security update and indicates that
it would be allowed, but does not describe filing the FESCo ticket that
the "Security Updates" section states as a requirement. These two
things should be made consistent. Maybe use a different package as an
example, since I think this is intended to illustrate something that
would require a Major version rebase in order to fix a security problem,
and which doesn't have an exception.
As a final suggestion, while I hate making the policy any longer,
perhaps the policy could start with an extremely brief "TL; DR", along
the lines of:
"Leaf" nodes MUST be Major-version stable. Everything else MUST be
Minor-version stable. Any more significant rebase MUST have a
standing exception from FESCo, or request a one-time exception from
FESCo.
If such a short summary is possible, then maybe the current bugzilla
remainders to "check the policy" before pushing an update can be improved.
While I expect that the majority of Fedora's maintainers understand
Semantic Versions and interface stability well, it might be helpful for
new packages (and occasionally for users) to add a footnote or sidebar
somewhere to provide background on why a stable interface is desirable,
and to provide definitions that help clarify what level of stability is
desirable for dependencies and for leaf nodes.
Definitions and rationale:
In order to understand why a stable interface policy is desirable, it is
necessary to understand the basics of Semantic Versioning.
In the Semantic Versioning system (https://semver.org/), the Major,
Minor, and Patch version numbers represent different types of changes as
they increment. When only the Patch level increments, users should
expect no interface changes, only backwards-compatible bug fixes. When
the Minor level increments, users should expect that new features or
interfaces may have been added, but all of the interfaces from prior
versions with the same Major version are still present and compatible.
When the Major version increases, then users should expect that
interfaces may had been removed or changed in incompatible ways.
When an application is built, it will use definitions provided by the
packages it depends on, and an application's source code and build
system may detect and use features that are present in the version of
the dependencies available at build time. That means that an
application's source code may be compatible with a wider range of
versions of its dependencies than the compiled version. Effectively,
assuming the correct use of semantic versions, a compiled application
should be compatible with any version of its dependencies are are equal
to or greater than the version present in its build environment, but
less than a version with a higher Major version number.
Because rpm package dependencies don't include the version of each
dependency present in the build environment, some dependency information
may be hidden.
In a distribution that is Major-version stable (or "compatible interface
stable"), the only supported configuration is fully patched. It is not
guaranteed to be safe to install or update an individual package without
also patching all installed packages. It is possible to install a new
package and find that it does not work because it depends on a package
that was already installed, which satisfies the rpm dependency
information, but which is older than the version that was present in the
new application's build environment and does not provide all of the
features and interfaces defined during that build.
As an illustration, assume that on the day a Fedora release is
published (day 0), a repository is fully consistent. Everything has
been built together, so every package that expresses a dependency is
implicitly a dependency on a package of the correct version. On day
1, an update is published for libFoo; it is updated from version
1.1.0 to version 1.2.0, which adds some new library functions and
changes some macros to use them. That update does not, however,
change the soname, and the library does not provide a symbol map for
internal versioning. On day 2, an update is published for appBar; it
is updated from version 1.0.1 to version 1.0.2. appBar depends on
libFoo.
Is it safe for users who installed appBar on day 0 to update from
version 1.0.1 to 1.0.2?
Most users would conclude that it is, because that update is a
patch-update meant to address a security problem. However, appBar
has a hidden dependency. It visibly depends on libFoo, but it
invisibly depends on version >= 1.2.0. Users who update appBar and
don't fully patch their system at the same time might see errors as
a result.
In a distribution that is Minor-version stable (or "feature stable"), it
is reasonably expected to be safe to selectively install individual new
packages and updates. All of the dependencies should match the Major
and Minor versions that were present in the build environment, because
those are stable during the life of the release.
_______________________________________________
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
