Re: Bug#17621: [PROPOSED]: About versions based on dates

[Joey Hess <joey@kitenet.net>]

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