Changing the APT versioning scheme?
So,
we've been discussing adding pkg-config support to apt for quite
some time, most recently in https://salsa.debian.org/apt-team/apt/merge_requests/20.
pkg-config does not support prereleases of software. This is a big
problem, given that apt in the current scheme is in a pre-release
version scheme until after a Debian or Ubuntu freeze happens.
The current versioning scheme so far is that odd versions have
9 months of support, and even numbers longer support; due to
the freeze and release schedules of recent Debian and Ubuntu
releases, which I quite like (1.2 is xenial, 1.4 is stretch,
1.6 is bionic, and 1.8 will be buster).
We could consider changing to a different versioning scheme, such
as:
* X.Y.700-X.Y.799 for alphas, X.Y.800-X.Y.899 for betas, and
X.Y.900-X.Y.999 for rcs.
* Use an even/odd version numbering scheme, where e.g. 1.9.X is
the development series leading to the 2.0 release.
* Just start with 1.9.0 and freeze at a random 1.9.x release
I think having the ~alpha and ~beta labels also creates some
uncertainty with regards to how stable it is, when in practice
they are different levels of feature completionness (with beta
being restricted to smaller features, and rcs to bugfixes only).
In general, I think we believe that all commits of apt/master offer a stable program
- I use daily builds, and DonKult just runs straight from git, after
all. And especially ~rc builds are tricky, as the freeze policy for
them is the same as for stable releases (well, slightly more strict
maybe, when it comes to the Ubuntu stable releases, as we do occasionally
backport an important feature).
It might therefore make sense to just drop the ~alpha, ~beta,
~rc terminology in the version number, and just start with 1.9.0,
and freeze at a random 1.9.X.
Any other ideas, concerns, comments?
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: