On 2022-01-23 Thomas Dickey <dic...@his.com> wrote: > From: Richard Laager <rlaa...@debian.org> >> On 1/23/22 10:04, Thomas Dickey wrote: [...] >> I see no other way to correct this but to add an epoch.
> agreed. Is there some way to further improve the transition? >> As we see in this case, switching from version numbers to date-based >> versions is dangerous because it's impossible to go back without an >> epoch. A better version would have been something like >> 1.9.1+20050505. > I suspect that providing an interim 1.9.1+20140715 with/without an epoch > would have problems going backward. But there might be some way to do that. [...] Hello, afaiui Richard was pondering the time machine solution - Whether the 2005 upload should have have used 1.9.1+20050505 instead of 20050505. It is not a viable solution anymore. >> Lintian flags on this, but (according to the name and description) only for >> new packages: >> https://lintian.debian.org/tags/new-package-uses-date-based-version-number >> Personally, I'd like to see that lintian check fire if the date-based >> versioning is new. That is, it should fire if the previous changelog entry >> did not have a date-based version. > yes... but it's a little late for that (I've only learned about these > issues in the process of setting up the upgrade). >> Even better would be a dak (or whatever ftp-master tool is relevant) hard >> fail if going from non-date-based to date-based at the front of the version >> string. It might help a little bit but I suspect that very often at the time the upload with the date-based version hits the Debian archive the version number is already entrenched. - There might have been lengthy discussions before or packages with the new numbering have been shipped at other places like other major distros. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
