On Aug 24, 2009, at 7:31 PM, Andreas Rottmann wrote:
The mapping can probably be the identity in many cases, however. If
there is no "natural" mapping, we could use <year>.<month>.<n>, or
<year>.<month>.<day>. A problem might be if there *is* a natural
(e.g. identity) mapping, but there are packages available from $VCS
as a
well. This complicates things -- you have to be careful so that the
version order relationship is kept. I can not see how to solve this
issue without resorting to a (slightly?)) more complicated versioning
scheme.
A slightly more complex scheme can be dash-separated list of versions
each of which is a dot-separated list of numbers (e.g., 12.3.4-0.1).
So, you can use <year>.<month>.<day>-<rev> or even
<relyear>.<relmonth>.<relday>-<revyear>.<revmonth>.<revday>.
As an example, consider a spells as an hypothetical example:
As of now, there are no releases of spells, so spells gets initially
packaged as "0.0.2009.11.03" by someone other than me (the intention
of the leading zeros is to have it sorted before subsequent
releases).
So, that can be called "0-2009.11.03" or "0.0-2009.11.03".
Now I might be unaware of this packaging effort (yeah, this
example is somewhat contrived), and might release a spells in
Dezember
versioned "0.0.1"; "0.0.2009.11.03" > "0.0.1" -- Houston, we have a
problem.
So, that can be now "0.0.1-2009.12.01" or whatever. Think about
each version number as a stream: up/mid/down-stream versions.
Debian works around that by using an extended versioning scheme
(see the
Debian Policy Manual, Section 5.6.12 [0] for the gory details).
I know about that and would rather not go there. Debian has to work
with existing packages that have all sorts of weird stuff. We don't.
If we use the upstream version as is, we would get into trouble
trying
to interpret these versions.
In the general case, yes. Upstream might have an insane numbering
scheme, but I think this is an exception, and most upstream release
numbers can be used with little or no mangling, if you relax the rules
for version numbers a bit (as Debian does).
I think they would still be used with little or no mangling anyways
(since the upstream packages are, for the most part, noninexistent
yet :-))
The upstream version can probably be included in the meta data for
documentation purposes, but I don't see how we can use it for any
purpose.
I think we should either:
1) Try to use the upstream version number, with a little mangling (if
needed), if at all possible.
Or:
2) Don't use the upstream version number for anything, just have a
package version, and include the upstream version in the manifest.
I lean towards (1); I think just having to look at the filename and
having a very good chance of figuring out what version you'll get is
surely useful.
I think we're in agreement here. The existing two libraries can
probably map to the proposed version scheme with little or no
mangling. :-)
Aziz,,,
