Clarification on packaging latest versions of software #1549

New issue

Open

opened 2026-06-24 10:32:48 +00:00 by ankursinha · 4 comments

ankursinha commented

2026-06-24 10:32:48 +00:00

Member

Context

Ever since I can remember, I've always packaged the latest version of software. This was in the review template I had picked up ages ago, and it's now in the "standard" template that Fedora review (and the service) use:

[ ]: Latest version is packaged.

However, i see that the guidelines don't really say this. A few language specific ones say "latest SHOULD ..", but the general guidelines provide no advice/direction on whether this needs to be done.

Catalyst

A case that I've just run into is this review:

https://bugzilla.redhat.com/show_bug.cgi?id=2491110

Here, an older version of a general purpose python package (exa-py) is being packaged because the application it's being packaged for (hermes-agent) pins it to this older version.

While this unblocks hermes-agent in the short term it produces a few long term issues:

standalone users: human users that this package can be used by independently will now not get the latest version with fixes/enhancements---probably ever because hermes-agent will always pin to an older release.
losing the "system package" nature: the package is effectively a "private dependency", and not a system wide package for general use---not by humans, nor by other packages that may require more recent versions

My historical understanding of the spirit of the guidelines has been that we always package the latest versions (independent of what depends or may depend on it in the future). This is because each package is treated as an independent system package.

Even after a package has been included, we try to update packages to their latest versions---independently of packages that depend/may on them. We do impact checks and if dependent packages break, we help packagers/upstreams port their code to support the new version as much as possible. I consider this an important duty of package maintainers (and perhaps the category of task that takes more time than anything else we do).

Packaging older versions feels weird to me. An extension is that then we don't need to update already packaged bits either---not shared objects, or other packages---until every dependent package has caught up.

I understand that this is something that should be left as a SHOULD to allow sufficient leeway in complex cases, but perhaps some guidance on this would be useful---similar to how we have guidance on bundling where we say that "Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package" with some text explaining why.

(Note: I also see that the bundling guidelines does not really explain why bundling should be avoided---i found this wiki page explaining it that should perhaps be linked to/moved into the docs somewhere: https://fedoraproject.org/wiki/Bundled_Libraries ? I'll file a separate ticket for this, though).

## Context Ever since I can remember, I've always packaged the latest version of software. This was in the review template I had picked up ages ago, and it's now in the "standard" template that Fedora review (and the service) use: ``` [ ]: Latest version is packaged. ``` However, i see that the guidelines don't really say this. A few language specific ones say "latest SHOULD ..", but the general guidelines provide no advice/direction on whether this needs to be done. ## Catalyst A case that I've just run into is this review: https://bugzilla.redhat.com/show_bug.cgi?id=2491110 Here, an older version of a general purpose python package (exa-py) is being packaged because the application it's being packaged for (hermes-agent) pins it to this older version. While this unblocks hermes-agent in the short term it produces a few long term issues: - standalone users: human users that this package can be used by independently will now not get the latest version with fixes/enhancements---probably ever because hermes-agent will always pin to an older release. - losing the "system package" nature: the package is effectively a "private dependency", and not a system wide package for general use---not by humans, nor by other packages that may require more recent versions ---------------- My historical understanding of the spirit of the guidelines has been that we always package the latest versions (independent of what depends or may depend on it in the future). This is because each package is treated as an independent system package. Even after a package has been included, we try to update packages to their latest versions---independently of packages that depend/may on them. We do impact checks and if dependent packages break, we help packagers/upstreams port their code to support the new version as much as possible. I consider this an important duty of package maintainers (and perhaps the category of task that takes more time than anything else we do). Packaging older versions feels weird to me. An extension is that then we don't need to update already packaged bits either---not shared objects, or other packages---until every dependent package has caught up. I understand that this is something that should be left as a SHOULD to allow sufficient leeway in complex cases, but perhaps some guidance on this would be useful---similar to how we have guidance on bundling where we say that "Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package" with some text explaining why. ------------ (Note: I also see that the bundling guidelines does not really explain why bundling should be avoided---i found this wiki page explaining it that should perhaps be linked to/moved into the docs somewhere: https://fedoraproject.org/wiki/Bundled_Libraries ? I'll file a separate ticket for this, though).

farchord commented

2026-06-24 11:19:52 +00:00

Member

Maybe also include a soft-exception if the dependancy in Fedora is too old, or if the intent is to package it into a branch that does not have the appropriate build requirements for it (F43 currently). It's also possible that for some weird reason, the latest version introduced a reduction in functionality.

decathorpe commented

2026-06-24 19:07:27 +00:00

Owner

Maybe "SHOULD package the latest version" can be added to the checklist here?

https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_things_to_check_on_review

On the other hand, that checklist (and the whole page) are rather dated ...

Maybe "SHOULD package the latest version" can be added to the checklist here? https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_things_to_check_on_review On the other hand, that checklist (and the whole page) are rather dated ...

carlwgeorge commented

2026-06-24 21:51:39 +00:00

Owner

Maybe also include a soft-exception...

Per RFC 2119, SHOULD guidance basically includes "soft-exceptions" already, so I don't think we need to spell that out explicitly in our guidelines.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

> Maybe also include a soft-exception... Per [RFC 2119](https://www.rfc-editor.org/info/rfc2119/), SHOULD guidance basically includes "soft-exceptions" already, so I don't think we need to spell that out explicitly in our guidelines. ``` 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ```

👍 2

james commented

2026-06-25 16:32:46 +00:00

Owner

Yeh, I think the expectation/wording comes from the old times where people would manually publicly release via. a tarball somewhere ... now we live in a world where every git commit can be a release.