Josip Rodin <j...@srce.hr> writes: > The Policy section "Version numbers based on dates" recommends using > simply YYYYMMDD for versions based on dates.
> However, it is not uncommon for upstream authors to release date-based > versions for betas, and then later switch to e.g. 1.0 for "proper" > releases. In such cases, people who used YYYYMMDD need to use epochs to > switch to X.Y. > This would be fixed by recommending to prepending additional zeros to > YYYYMMDD. I would probably go for 0.0.YYYYMMDD. Someone else might want > more? The text referred to in this bug is section 3.2.1, which says: In general, Debian packages should use the same version numbers as the upstream sources. However, in some cases where the upstream version number is based on a date (e.g., a development "snapshot" release) the package management system cannot handle these version numbers without epochs. For example, dpkg will consider "96May01" to be greater than "96Dec24". To prevent having to use epochs for every new upstream version, the date based portion of the version number should be changed to the following format in such cases: "19960501", "19961224". It is up to the maintainer whether they want to bother the upstream maintainer to change the version numbers upstream, too. Note that other version formats based on dates which are parsed correctly by the package management system should _not_ be changed. Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should always use the "YYYYMMDD" format. I agree that we shouldn't be recommending YYYYMMDD alone for upstream snapshot releases for the reasons stated in the bug report. The bug report predates the introduction of ~, though, which now offers a better solution to this problem than was available. However, I think this whole bit really doesn't belong in Policy. For packages that are snapshot-based with no regular version number but one that might show up later, I'd use 0~YYYYMMDD. For ones that are pre-releases, I'd use <new-version>~YYYYMMDD. For ones that postdate an existing version, I'd use <old-version>+YYYYMMDD. But all of that feels like best practices stuff. Similarly, I'm not seeing why we should say YYYYMMDD should be used for Debian native packages, as opposed to YYYY.MM.DD or some other format that sorts properly. I therefore think we should rewrite this whole section to remove most of the details and instead just say not to ever use date-based formats like 96May01 and instead use something based off of YYYYMMDD, possibly with punctuation (but not -). If that sounds good, I can work on new language. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org