Abdulaziz Ghuloum <[email protected]> writes: > On Aug 24, 2009, at 6:23 AM, Andrew Reilly wrote: > >> For what it's worth, that's pretty close to how the FreeBSD >> ports system works: upstream versions are the main part, and >> "port revisions" (i.e., changes to the associated FreeBSD ports >> makefile/patch-file/etc infrastructure) are marked with a ",nn" >> suffix. Comma is nice here, because it is not often used as >> part of up-stream package names, which sometimes *do* include >> hyphens and trailing digits. > > I don't think Andreas suggested that we use the upstream > version as is, instead, it would be mapped by the package > maintainer to some version that matches "n(.n)*" followed > by an optional "-n" indicating the package (not upstream) > version number. > 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. 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). 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. Debian works around that by using an extended versioning scheme (see the Debian Policy Manual, Section 5.6.12 [0] for the gory details). The version comparison algorithm additonally allows alphabetic parts, as well as '+', '~' and ':'. In Debian, the above example would work out by having a version of e.g. 0~git20091103 (assuming there would never be a release "0", which is quite reasonable). This would sort before any version starting with "0.". Packages from git after the 0.0.1 release would then be versioned "0.0.1~git<date>". [0] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > 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). > 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. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
