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