Manoj Srivastava wrote: > 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) dpkg cannot handle these > version numbers currently, 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 > version number should be changed to the following format in such > cases: `1996-05-01', `1996-12-24'. It is up to the maintainer whether > he/she wants 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 dpkg 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 `YYYY-MM-DD' format.
I prefer to take a "don't fix it until it breaks" approach. For example, my package, lambdacore, has had the following upstream releases: 1oct94 02feb97 Now though this is obviously not a numbering scheme dpkg can handle, as luck would have it, these version numbers have compared correctly under dpkg so far. Given the rate of upstream releases, I might not see another upstream release until 2000, and the chances are about 15 to 1 that the new upstream release will happen to version compare "correctly". So I don't see a reason to fix it. If a new version comes out in 2 days, of course, it will not version compare correctly, and so I'll then have to go to a sane version numbering scheme. But why impose one before I really need to? -- see shy jo
