[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy Weekly Issue #4/8: Dates in package versions



-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 24 Oct 1997, Ian Jackson wrote:

> > Some upstream sources use a `snapshot date' instead of a real version
> > number. As these `dates' are used as version id for dpkg it is useful to
> > make them all use the same format. (It doesn't matter if our version
> > number _looks_ different than the one from the upstream source when a date
> > is used.  For example, everyone should be able to recognize that `96May05'
> > is the same as `1996.05.05'.) 
> 
> I disagree strongly.  In general we have a good correspondence between
> upstream and Debian version numbers.  I don't think that we have to or
> should make an exception to the usual policy of trying to keep our
> version numbers close to the upstream ones.
> 
> Of course a version number may need to be reformatted to get it to
> sort properly, but IMO the minimal change should be made which has
> this effect.
> 
> Furthermore, implementation of this policy would require changes to
> the version numbering of many existing packages, which would require
> epochs in some cases and in any case be confusing.

Ok, let's relax the requirements:

Encouraged standards for dates:

1. Preferred:       YYYY.MM.DD or YYYY.MM
2. Less preferred:  YYYYMMDD or YYYYMM

How much do we encourage the standards:

* Newly created Debian-specific packages using dates should use YYYY.MM.DD
or YYYY.MM format.

* Already existing Debian-specific packages should move to one of the
encouraged standards if doing so does not make them to need an epoch.
[ Note that some packages would need an epoch if they move to 1) but not
if they move to 2) ]

* Upstream sources using braindead [*] numbering schemes (like "96May05") 
should move to 1) as soon as possible even if an epoch is needed.

* We shall consider upstream sources using 2-digit years as an
"oddity". This should be considered as a bug (wishlist), but we will
not fix it until it is fixed upstream.


[*] braindead: anything which may, in principle, require a lot of
epochs if we insist on keeping the upstream version number untouched.
Examples: Using month names, or putting year after month, etc.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNFCDnSqK7IlOjMLFAQEBRwP/Tm9CqB7CfIkEWGcaKsrGefO9D9y/VzGP
RPtKbb+i2g4RHPrJVQXoIaTmw+8mxA/JzO55QUn/uWDUP6A+F9NtrLbliBCNBAID
RHKcdzJ/YHGdFPELap2mYzZw6p2mJlM5TWvm01F9Tv7iOut23hkK5MqtkpgG7ptD
HvAGfpRYXjM=
=0omL
-----END PGP SIGNATURE-----


Reply to: