Differences between revisions 2 and 5 (spanning 3 versions)
Revision 2 as of 2009-03-28 01:15:28
Size: 1310
Editor: 67
Comment: Added my crazy moon proposal. --Larry Hastings
Revision 5 as of 2009-03-28 04:12:16
Size: 2562
Editor: adsl-70-131-128-167
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
* A version string should be transformable into a version tuple.
* Version tuples are tuples of arbitrary length containing only integers.
* A version tuple conceptually ends with an infinite number of 0 fields; (1,3) == (1, 3, 0, 0, 0)
* While you see integers, accumulate them, and when it's done int().
* While you see alphanumerics, accumulate them, and when it's done map it if it's a known string ("alpha", "beta") otherwise break up the characters into individual numbers.
* Pre-releases (alpha, beta) are represented by having a negative number in the version tuple.
* When you compare version tuples, if there are any negative fields, split there and compare the non-negative parts first.
 * A version string should be transformable into a version tuple.
 * Version tuples are tuples of arbitrary length containing only integers.
 * A version tuple conceptually ends with an infinite number of 0 fields; (1,3) == (1, 3, 0, 0, 0)
 * While you see integers, accumulate them, and when it's done int().
 * While you see alphanumerics, accumulate them, and when it's done map it if it's a known string ("alpha", "beta") otherwise break up the characters into individual numbers.
 * Pre-releases (alpha, beta) are represented by having a negative number in the version tuple.
 * When you compare version tuples, if there are any negative fields, split there and compare the non-negative parts first.
Line 17: Line 17:

=== Erik LaBianca ===

Just throwing this out there since it's a little different from what was discussed earlier, but I think has some merit:

* Versions are a series of integers. Ie 0.0.1, 1.0.0, or 12.5.7.9. Versions define the "intended API level" of the software in question.

Pre-release versions are denoted by a version, followed by a string (I suggest "pre" but it doesn't really matter), followed by a series of integers, seperated by periods if needed. Pre-releases are important because while they may be an implementation of a future API version, they are likely to be buggy or incomplete.

* For instance 1.0.0pre2.1 > 1.0.0pre2 > 1.0.0pre1 < 1.0.0.

* Or for the case of daily builds, 1.0.0pre1 > 1.0.0pre0.20090327 < 1.0.0

This obviously trades away the flexibility of roll-your-own naming entirely, but makes up for it by defining a standard that leaves enough flexibility to represent most cases easily. It is easy to parse and explain, extensible, and able to cover most use cases aside from that of "backported bug fixes". I believe that eliminating words will be a net positive because it eliminates any complaints along the lines of "you included alpha, beta, and rc but where's pre-release or testing?!".

Describe DistutilsVersionFight here.

Larry Hastings

Sorry for the crazy moon proposal here, but I have example code that I think even works. (Though I'm not operating on enough sleep, so sorry 'cause I already know the code is crappy.) lch.version.py

The basic idea:

  • A version string should be transformable into a version tuple.
  • Version tuples are tuples of arbitrary length containing only integers.
  • A version tuple conceptually ends with an infinite number of 0 fields; (1,3) == (1, 3, 0, 0, 0)
  • While you see integers, accumulate them, and when it's done int().
  • While you see alphanumerics, accumulate them, and when it's done map it if it's a known string ("alpha", "beta") otherwise break up the characters into individual numbers.
  • Pre-releases (alpha, beta) are represented by having a negative number in the version tuple.
  • When you compare version tuples, if there are any negative fields, split there and compare the non-negative parts first.

I doubt y'all will go for this. But I thought you should at least consider supporting a more flexible format. People like to express their version numbers a wide variety of ways, and most folks could find a way to map their personal weird approach to something this approach would make consistent.

Erik LaBianca

Just throwing this out there since it's a little different from what was discussed earlier, but I think has some merit:

* Versions are a series of integers. Ie 0.0.1, 1.0.0, or 12.5.7.9. Versions define the "intended API level" of the software in question.

Pre-release versions are denoted by a version, followed by a string (I suggest "pre" but it doesn't really matter), followed by a series of integers, seperated by periods if needed. Pre-releases are important because while they may be an implementation of a future API version, they are likely to be buggy or incomplete.

* For instance 1.0.0pre2.1 > 1.0.0pre2 > 1.0.0pre1 < 1.0.0.

* Or for the case of daily builds, 1.0.0pre1 > 1.0.0pre0.20090327 < 1.0.0

This obviously trades away the flexibility of roll-your-own naming entirely, but makes up for it by defining a standard that leaves enough flexibility to represent most cases easily. It is easy to parse and explain, extensible, and able to cover most use cases aside from that of "backported bug fixes". I believe that eliminating words will be a net positive because it eliminates any complaints along the lines of "you included alpha, beta, and rc but where's pre-release or testing?!".

Distutils/VersionComparison (last edited 2009-05-11 08:52:26 by dslb-088-064-058-218)

Unable to edit the page? See the FrontPage for instructions.