Edgar Fuß <ef%math.uni-bonn.de@localhost> writes: >> I don't like "pre" or "rc", as they are often used by upstream programs. > Can you give me an example for "pre" being used by upstream? There are a lot. From my distfiles directories: w3-4.0pre.47.tar.gz wistumbler2-2.0pre10.tar.gz elinks-0.12pre6.tar.bz2 abook-0.6.0pre2.tar.gz dovecot-antispam-1.3-pre1.tar.bz2 links-1.00pre20.tar.gz mc-4.1.40-pre9.tar.gz mdbtools-0.6pre1.tar.gz ninka-1.0-pre2.tar.bz2 spatt-2.0-pre7.tar.gz wahcade-0.99pre8.tar.gz (I did a bulk fetch of wip at some point so there are some odd things here.) As far as I can tell, pre is more or less like alpha, beta, rc except that it doesn't mean any of those -- just that it is leading to release. >> Also, pre and rc tend to mean that foo-2.1pre1 is actually before foo-2.1. > That's true, yes. > >> So I suggest "ur" to mean "unreleased", and to add it as a separator >> token, with the rule that a version is > Isn't that exactly what "pre" means? First we have to define "released". There are two meanings. One is when upstream considers something a proper release. The more important one for pkgsrc is when upstream makes available a distfile with a version number. It is really upstream having a tarball with a version number that matters. For example, if we were to packaage links-1.00pre20.tar.gz, it has a version number and there is no problem (other than the issue of whether users are better served with that vs. 0.99 release). The issue I thought we were discussing is when upstream has not made available a tarball with a version number -- but that we think we should use some sha1/date/svn-rev instead from their VCS. That can be either because they have not yet made a release, or because a release is long overdue. I see those two situations as very similar and would like us to be consistent about it. I see the "ur" tag (or whatever it is) as a way to say that this version does not correspond to an upstream tarball, and is instead a snapshot From a VCS. But versions like this have to sort properly with real versions. In general, we don't know what the next version is going to be. So I think we need something that is after a previous version. That is messy when there has been none, as there could be a "0". For upstreams that have never had a release, we could just use "ur20160610" as the version, and declare that any version sorts after the empty version (in our pkgsrc-local version comparison code).
Attachment:
signature.asc
Description: PGP signature