Re: Policy Weekly Issue #4/8: Dates in package versions
> * Newly created Debian-specific packages using dates should use YYYY.MM.DD
> or YYYY.MM format.
As someone has noted, we should use -'s.
> * 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) ]
and
> * 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.
No. It is not for us to determine what the upstream version number
scheme should be (though we can say what we might like), and since it
is our policy to try to keep the upstream version number intact as
much as possible it is NOT a bug if this results in us using a version
number with a 2-digit year.
Furthermore, existing packages should NOT change. We should keep our
version numbers as similar as possible to the upstream ones. We
should maintain the current policy of only changing the upstream
numbering scheme if it doesn't sort properly.
> * Upstream sources using braindead [*] numbering schemes (like "96May05")
> should move to 1) as soon as possible even if an epoch is needed.
Upstream sources using numbering schemes which do not sort properly
should have the number transformed to a scheme which does, but which
is as close as possible to the original.
For example, 96May05 should be changed to 96-05-05.
This is already policy, I believe. If this is not stated it should
be.
Ian.
Reply to: