Standards-Version 4.7.4 was introduced during the development of Debian 14, but the version number doesn't reflect that.

Meanwhile, debhelper-compat 14 was introduced during the same development cycle and it indeed matches the upcoming Debian release version.

I propose that, from now on, Debian Policy switches to a 3-part version:

x.y.z

Where X denotes the Debian release (e.g. 14 for Forky) during which the policy was introduced, X denotes major changes in policy or packaging, Y denotes minor adjustments in policy or packaging.

As an example, the current 4.7.4 could be renumbered to 14.7.4 to reflect the ongoing development schedule.

Martin-Éric

Hi!

The problem is that the Debian Policy and debhelper are not alike. In
the Debian Policy case, major changes are added whenever, regardless of
a specific start of a Debian release cycle. For debhelper, incompatible
or breaking changes get accumulated in the next compat level and then
released, which makes it easy to sync with a Debian release cycle, and
by definition all those changes will be major.

Using the Debian release number for the Debian Policy would mean that
the first component would no longer imply major changes in the Policy,
just the time when they happened in the Debian release cycle.

Thanks,
Guillem

This is a pure coincidence, debhelper-compat 13 was introduced in debian 11.

Your proposal would require all maintainers to update their control file even
though there was no change to policy. 4.7.3, 4.7.4 and 4.7.4.1 are relatively
minor update that affect a minority of packages.

Cheers,

pe 17.7.2026 klo 15.27 Bill Allombert (ballombe@debian.org) kirjoitti:

I'd really like to know where you got this impression that this would
force people to bump the number in their control file for no reason.
Standards-Version merely is an indication of when the package's
compliance to Policy was last checked. For instance, many packages
still use debhelper-compat 13 and claim Standards-Version 4.6.2, etc.

The way I see it, the major digit would be a good ballpark indication
of when any major work was last done on a package's packaging, while
the whole number could point us closer to the exact timeframe. One
practical use for this would be to check for packages that haven't
seen any upgrade in a couple of releases. Combined with uscan
automation, it could be used to prod maintainers once in a while.

Martin-Éric

pe 17.7.2026 klo 15.19 Guillem Jover (guillem@debian.org) kirjoitti:

That would be the whole point. The first digit would now have a
concrete significance. It would indicate during which Debian release
cycle the packaging was last updated.

Martin-Éric

I think this detail is even less useful than Standards-Version itself as
it currently exists. Which problems will this solve?

To reword Guillem's point, the first digit does indeed have
an extremely concrete significance right now, pretty much semver-like,
and that is really useful IMHO.

G'luck,
Peter

control: tag -1 + wontfix

Martin-Éric Racine [17/Jul  3:04pm +03] wrote:

We won't change Debian Policy's existing version numbering scheme along
these lines.  Closing.

Andrey Rakhmatullin <wrar@debian.org> writes:

Indeed -- we made Rules-Requires-Root and Priority:optional irrelevant
recently, couldn't we also make Standards-Version an optional field?

In many packages, having that field just results in needless churn of
debian/ files.

/Simon

Simon Josefsson <simon@josefsson.org> writes:
for this reason given how much it apparently annoys people, but I've never
seen anyone provide a good solution for the primary use case I have for
Standards-Version: When I pick up a random package to update, I want to
know how far back in time I have to go in looking at the Debian Policy
upgrading checklist to see what I may need to update.

If people were religious about putting the Policy version they checked the
upgrading checklist for in the debian/changelog file, that would be
sufficient, but then that's the same amount of churn as just updating
debian/control, so....

Russ Allbery <rra@debian.org> writes:

Yeah, for people initimiately familiar with that checklist I suppose
that is a good use-case for this.  The information could be in a git
commit message though?

Personally, I've never found the upgrade checklist relevant for
per-package upgrades.  I find the checklist useful to understand what
changed between policy releases, but more as a curiosity to understand
general preferences over time.

This is because 1) the upgrade checklist often lacks concrete actionable
recommendations, or 2) for those things which ARE concrete and
actionable, lintian and the Salsa CI/CD pipeline are a more
cost-effective way for me to discover what I need to do.

Granted, I do run the risk of missing something really important that
the checklist say I should do.  I find the occasional bug report about
that a more cost effective way to go about incremental over-time changes
than having uploaders re-read the checklist for every package upload.

Alas, this ought to be a separate bug report for discussion to be
useful, and I'm not sure I feel strongly about this.  I may also be
lacking context about the history and relevance of this field.

/Simon