Package: devscripts
Version: 2.22.2
Severity: wishlist
File: /usr/bin/uscan
Many upstreams have the concept of prereleases and stable releases, or
development branches and stable releases, for example:
* GTK, GLib, Flatpak, SDL, dbus: x.odd.z is a prerelease, x.even.z is stable
- ([0-9]+.[0-9]*[02468].[0-9.]+) matches stable releases
- @ANY_VERSION@ matches all releases
* most of GNOME: 43.alpha, 43.beta, 43.rc2 are prereleases, 43.0 is stable
- [0-9.]+ matches stable releases
- @ANY_VERSION@ matches all releases
* Python: 3.10.0a1 and 3.10.0rc2 were prereleases, 3.10.0 is stable
- [0-9.]+ matches stable releases
- @ANY_VERSION@ matches all releases
For these projects it's often desirable to package prereleases in
experimental, and then promote a subset of releases to testing/unstable
(for example only including upstream stable releases in testing/unstable,
or including upstream release candidates and releases in testing/unstable
but not alphas or betas, or something similar).
One way to do that is to make debian/watch match both prereleases and
stable releases. However, while the version in experimental is ahead of
unstable, it's still useful to be notified about stable releases. For
instance, while we had GLib 2.73.x in experimental but 2.72.x in unstable,
being notified about 2.72.x releases would let us update unstable more
quickly.
It would be useful if there was a convention for doing this sort of
2-channel release monitoring, perhaps something like this:
- uscan without options: use debian/watch
- uscan --prerelease: try debian/watch.prerelease before debian/watch
Ideally, dehs could run in both modes if debian/watch.prerelease exists,
and do something like this:
- if newest prerelease is available and not in experimental: warn (low priority)
- if newest prerelease is in experimental but not unstable: remain silent
- if newest stable release is in experimental but not unstable: warn
- if newest stable release is in neither experimental nor unstable: warn
smcv
