On 17/08/2020 12:01, Holger Levsen wrote:
> hi,
> 
>  debian-security-support | 2019.12.12~deb8u2  | jessie-security          | 
> source, all
>  debian-security-support | 2020.06.21~deb9u1  | stretch                  | 
> source, all
>  debian-security-support | 2020.06.21~deb10u1 | buster                   | 
> source, all
>  debian-security-support | 2020.07.12         | bullseye                 | 
> source, all
>  debian-security-support | 2020.07.12         | sid                      | 
> source, all
> 
> is what we currently have in the archive and which is a bit of a hassle to
> maintain due to keeping version constraints sane (=newer releases should 
> always
> have higher versions) and since rather frequently there are changes only
> affecting older releases (so one has to upload to sid first, then do a stable 
> update and then update oldstable to propagate something which is only relevant
> for oldstable atm.)
> 
> Hence I propose to bump the epoch and introduce this versioning scheme:
> 
> sid:          0:11~2020.08.17
> bullseye:     0:11~2020.08.17
> buster:               0:10~2020.08.17
> stretch:      0:9~2020.08.17
> and so on.

A 0 epoch is equal to no epoch, so you need 1: here.

btw why keep the dates? I'd just do something like 11-1, 10-3, 9-5... The date
is still in the changelog if someone needs to look at it, but I don't think it
conveys any special information here. Anyway that's up to you. The epoch sounds
good to me to disentangle the updates as most of the time updates to d-s-s need
to happen to older releases, which carry older versions of packages, which are
no longer sustainable to maintain.

Cheers,
Emilio

Reply via email to