Version numbers for module distributions
There have been a few rumbles about module version numbering on and off the list, and I thought I should bring it all out into the open. First, I think I tossed off a random opinion along these lines: Module version numbers should follow the GNU standard: X.Y.Z, where X is the major version, Y is the minor version, and Z is the patch level. Alpha and beta versions can be noted by appending "aN" or "bN", where N is any integer. This is still my opinion, although John Skaller raised a bunch of issues on the list, and Greg Stein noted a minor wrinlke in private email. I'll address those momentarily. First, let me eludicate the position above. This was (roughly) my opinion going into the Developer's Day session back at the Python Conference, and when Eric Raymond said roughly the same thing (minus the bit about alpha/beta version) based on his experience running the giant sunsite archive, I was glad to hear I wasn't the only one who likes this scheme. (And after all, the GNU folks have a hell of a lot of experience in these matters, and they have been right before!) Finally, this seems to be the version numbering system that Guido uses for Python itself, which is another good precedent. To be formal for a moment: a version number must match the regular expression (ignore whitespace in the regex): (\d+) \. (\d+) \. (\d+) ([ab](\d+))? Two possible changes I would consider open to debate: * replace [ab] with [a-z], to allow test versions beyond "beta"... although any programmer who goes up to "zeta" (or should that be omega?) really needs to look at his quality control... ;-) * make the patch number optional (and treat 1.0 and 1.0.0 as the same version number) Yes, this is very rigid. But it also makes it pretty easy to parse, split up, and compare version numbers. Making alpha/beta numbers a formal part is, IMHO, necessary, because intuitively 1.0.0a1 should be less than 1.0.0 -- but no lexical or numeric comparison will draw this conclusion! Now, there should also be semi-formal guidelines on what the different components of a version number *for modules* might mean: * a major number of 0 means the module is still being actively developed and, while it may be ready for evaluation, nobody should depend on stability of interface or implementation * a change in the major number beyond 1 means a major change in the interface, possibly not backwards compatible with previous major releases * a change in the minor number means some new functionality has been added in a way that doesn't break the interface * a change in the patch level means bugs have been fixed without adding new functionality * an alpha version (X.Y.Z.aN) is an advance preview of a future release where the interface has not yet stabilized * a beta version (X.Y.Z.aN) is an advance preview of a future release where the interface has stabilized, but known bugs exist and are still being fixed These rules have a number of implications that hadn't occurred to me until just now, when I wrote them down. In particular, whole classes of version numbers make no sense at all. Having an alpha version of something with major number 0 (0.1a3) is silly, because that leading zero already implies an unstable interface. Likewise, having an alpha version of a release with a non-zero patchlevel (1.3.4a2) is silly for the opposite reason; a change in the patchlevel means only bugs are being fixed, so there's no new interface to be unstable. This of course directly contradicts the semantics of Python version numbers; witness 1.5.2a2. But Guido's allowed to make up his own semantics; I'm just suggesting rules for Python module distributions. Oh yeah, let me stress that: *module distributions*. If you distribute a bunch of modules together, they might each have a version number, *but* there should also be a version number for the whole distribution. (And the individual modules in the distribution could just go in lockstep with the distribution version, if you want.) Now I'll try to address John Skaller's points about the multidimensionality of software versions... Quoth John Skaller (2 December 1998):
No, that isn't enough. Consider:
MacVersion UnixVersion NTVersion
I think that platform differences can be handled by the naming scheme for built distributions. For instance, version 1.3.2 of module 'foo' might be distributed under the following names: foo-1.3.2.tar.gz # source distribution foo-1.3.2-sparc-sun-solaris2.tar.gz # 'dumb' built distribution # for a certain Unix platform foo-1.3.2-i386-linux.rpm # 'smart' built distribution # for one popular PC platform foo-1.3.2-win32.??? # 'smart' built distribution for # some obscure PC platform This of course assumes that the same source distribution applies to all platforms. This is a lot easier with modern programming languages like Python, Java, or Perl than with crufty old beasts like C or C++. (In the immortal words of Larry Wall, "C isn't so much portable as it is ubiquitous".) But lots of C and C++ programmers go to *great* effort to ensure that their source distribution is the same for all platforms, even if they need to resort to conditional compilation, complicated configuration scripts, etc. to make it so. I think for the restricted domain of Python modules (even those written in C or C++), we can assume that people will write cross-platform source distributions (or at least have them as a goal). Next issue:
Now consider:
FreeVersion Commercial Version
and then:
BareBones version Delux Version Everything including the Kitchen Sink Version
I see these are basically the same: different releases of essentially the same product but with varying degrees of functionality. (Where "functionality" might be defined as things like a license server for the commercial version. It could be argued that these *detract* from functionality, but let's not go there...) I'm not sure how to accomodate this one. A hack would be to give different names to the distributions: foo-1.3.2 for the standard free distribution, foo-commercial-1.3.2, foo-barebones-1.3.2, foo-delux-1.3.2 etc. for varying levels of functionality (and price!). However, again we come back to the fact that the product being distributed is *not* arbitrary software, but collections of Python modules together with their documentation and test suites. If you want different levels of functionality, you should split up your modules accordingly and make several distributions. Give away foo-base-1.3.2 to anyone who wants it, and charge extra for foo-bronze-1.3.2, foo-silver-1.3.2, and foo-gold-1.3.2, each of which contain a couple of modules that add still more functionality to the whole system. I think a lot of "version" problems can be solved by carefully organizing your modules so that blocks of functionality (barebones vs deluxe, informix vs sybase, etc.) correspond to modules or blocks of modules. Hell, this is just good solid software engineering practice, so you should be doing it that way anyways. That answer should also suffice where you have non-cross-platform source code (which is about the only reason I can think of for having platform-specific source releases). Finally, Greg Stein raised the following wrinkle in private email:
I wanted to briefly let you know that Apache modules are typically versioned as: 0.9.3-1.3.3. The first set refers to the module itself. The second set refers to Apache (which is currently at 1.3.3).
Good point! I certainly hope we don't have to deal with this, i.e. have module developers worry whether their module will work with Python 1.5.2 or 1.6 or 1.6.1 (etc.). There is, however, the distinct possibility of API breakage with Python 2.0, which could affect potentially all extension modules. Umm, I think I'll let Guido handle this one, if he's still reading this SIG...
Greg Ward writes:
Now, there should also be semi-formal guidelines on what the different components of a version number *for modules* might mean:
Disagreement; I'd vote for mechanism, not policy. For example, recently I went through 3 pre-releases of xml-0.5; they could have been called 0.5a{1,2,3}. ILU's been at 2.0a{1-12}, and I have no idea if the developers ever plan to go to beta. Different developers use version numbers differently, in ways that are consistent in the large but inconsistent in small details. A side note: for the XML package, I think things are getting to the point that I want to create a fake build tree (the blib/ idea) in order to allow running the test suite without having to actually perform the installation. So, is there any implementation work that can be done? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Once you accept that the world is a giant computer run by white mice, all other movies fade into insignificance. -- Mutsumi Takahashi, on _The Hitch-hiker's Guide to the Galaxy_
Andrew M. Kuchling writes:
Disagreement; I'd vote for mechanism, not policy. For example, recently I went through 3 pre-releases of xml-0.5; they could have been called 0.5a{1,2,3}. ILU's been at 2.0a{1-12}, and I have no idea if the developers ever plan to go to beta. Different developers use version numbers differently, in ways that are consistent in the large but inconsistent in small details.
I don't see any problem with offering mechanism in the software and a short set of guidelines in documentation. Perhaps the docs should indicate that if the guidelines are not followed, perpetrators will be tossed over... er, they should describe how they are using the parts of the number in their documentation.
A side note: for the XML package, I think things are getting to the point that I want to create a fake build tree (the blib/ idea) in order to allow running the test suite without having to actually
On this topic, it may make sense for the xml package to be a directory within the package, rather than the package toplevel. So xml-VERSION.tar.gz would expand to: xml-VERSION/ xml/ dom/ sax/ parsers/ utils/ ... doc/ README ...
perform the installation. So, is there any implementation work that can be done?
I think a version number "object" that can handle parsing and comparison is a clear need and fairly straightforward to implement. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Quoth Andrew M. Kuchling, on 10 December 1998:
Disagreement; I'd vote for mechanism, not policy. For example, recently I went through 3 pre-releases of xml-0.5; they could have been called 0.5a{1,2,3}. ILU's been at 2.0a{1-12}, and I have no idea if the developers ever plan to go to beta. Different developers use version numbers differently, in ways that are consistent in the large but inconsistent in small details.
Module developers are perfectly free to use illogical version numbers if they wish. I certainly don't intend to enforce through code the version number *guidelines* that I proposed, nor do I intend to check for the version numbers occupying the "illogical" subsets of version-number-space. I just wanted to point out the possible consequences of *that particular* set of guidelines. If anyone has suggestions for version number guidelines that don't have unexpected consequences, I'd like to hear 'em. (Of course, such guidelines should be short, simple, and obvious. That's what I like about my proposal.)
A side note: for the XML package, I think things are getting to the point that I want to create a fake build tree (the blib/ idea) in order to allow running the test suite without having to actually perform the installation. So, is there any implementation work that can be done?
Yeah, the distutils.build module. It would have to be told various lists of source files (for a start: .py, ancillary .c files, and extension .c files) and then would Do The Right Thing: copy .py into blib, compile to .py and .po, compile all .c files, and link ancillary .o with extension .o to make .so. (Platform independence can come later.) Of course, we haven't really looked at the existing extension-building systems, e.g. the interface put on the table by John Skaller. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
...
A side note: for the XML package, I think things are getting to the point that I want to create a fake build tree (the blib/ idea) in order to allow running the test suite without having to actually perform the installation. So, is there any implementation work that can be done?
Yeah, the distutils.build module. It would have to be told various lists of source files (for a start: .py, ancillary .c files, and extension .c files) and then would Do The Right Thing: copy .py into blib, compile to .py and .po, compile all .c files, and link ancillary .o with extension .o to make .so. (Platform independence can come later.)
IMO, a distutils test harness only needs to compile a .pyo. There isn't a need to do both because we can presume the Python interpreter has the appropriate testing. -g -- Greg Stein, http://www.lyra.org/
Greg Ward writes:
* replace [ab] with [a-z], to allow test versions beyond "beta"... although any programmer who goes up to "zeta" (or should that be omega?) really needs to look at his quality control... ;-)
Make it [ab] and don't change it unless there are substantial complaints (meaning someone actually wants to use something else and can present a good argument for doing so, *not* that someone might theoretically want to).
* make the patch number optional (and treat 1.0 and 1.0.0 as the same version number)
Definately. In fact, I'd want to hide the patch number if it's 0. If the version number class is distutils.version.Number, this should happen: >>> from distutils.version import Number >>> v = Number("1.0.0a1") >>> str(v) '1.0a1'
Quoth John Skaller (2 December 1998):
No, that isn't enough. Consider:
MacVersion UnixVersion NTVersion
I think that platform differences can be handled by the naming scheme for built distributions. For instance, version 1.3.2 of module 'foo' might be distributed under the following names:
I agree. The version number should not be platform dependent, as that can only create confusion.
Now consider:
FreeVersion Commercial Version
and then:
BareBones version Delux Version Everything including the Kitchen Sink Version
I see these are basically the same: different releases of essentially the same product but with varying degrees of functionality. (Where
These are different products and should have different base names. Your examples describe this effectively.
Finally, Greg Stein raised the following wrinkle in private email:
I wanted to briefly let you know that Apache modules are typically versioned as: 0.9.3-1.3.3. The first set refers to the module itself. The second set refers to Apache (which is currently at 1.3.3).
This is a dependency issue, and the dependency checking component should be able to deal with version numbers as appropriate. This is how other packaging systems deal with it (to the best of my knowledge, which is not comprehensive ;). -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Fred L. Drake wrote:
...
Finally, Greg Stein raised the following wrinkle in private email:
I wanted to briefly let you know that Apache modules are typically versioned as: 0.9.3-1.3.3. The first set refers to the module itself. The second set refers to Apache (which is currently at 1.3.3).
This is a dependency issue, and the dependency checking component should be able to deal with version numbers as appropriate. This is how other packaging systems deal with it (to the best of my knowledge, which is not comprehensive ;).
This is bunk. I'm not putting it there for an automated tool! It is there for the *USER* to figure out which one he wants. What about when I publish 1.1.3-2.0.1 and maintain *both*. And I strongly agree with Marc-Andre about staying out of the semantics of the version numbers. I'll use a format for the automated tool, but stay away from *my* semantics. I would also argue very strongly more more flexibility in the format schemes. For example, looking at the RedHat 5.1 distribution, I see a few formats: xzip-161-2.i386.rpm yp-tools-1.4.1-2.i386.rpm xv-3.10a-10.i386.rpm xrn-8.02-7.i386.rpm xpm-3.4j-2.i386.rpm xmorph-1996.07.12-4.i386.rpm xboard-3.2.pl0-9.i386.rpm x3270-3.1.1.6-2.i386.rpm spice-2g6-7.i386.rpm sox-11g-7.i386.rpm rdate-0.960923-4.i386.rpm nfs-server-2.2beta29-5.i386.rpm nenscript-1.13++-11.i386.rpm mailx-5.5.kw-9.i386.rpm dhcp-2.0b1pl0-2.i386.rpm I can draw a number of conclusions from this about types of formats that need to be allowed. But that's a straight-forward exercise. The point is: You have to be MUCH more flexible in what you can take for the version number. You cannot legislate a numbering scheme to the masses. It simply won't work because too many people have an idea of the "right" way to number. As long as you can specify rules for HOW numbers will be compared, then you're okay. For example: 1) a version number has 1 or more numbers separate by a period or by sequences of letters. If only periods, then these are compared left-to-right to determine an ordering. 2) sequences of letters are part of the tuple for comparison and are compared lexicographically 3) recognize the numeric components may have leading zeroes That should be about it. Welcome to Other Peoples' Versioning. Have a nice stay. :-) -g -- Greg Stein, http://www.lyra.org/
There have been a few rumbles about module version numbering on and off the list, and I thought I should bring it all out into the open. First, I think I tossed off a random opinion along these lines:
[lots of arguments deleted because I agree completely]
Now, there should also be semi-formal guidelines on what the different components of a version number *for modules* might mean:
Better formal ones. If you feel you need more precision to indicate subtle variations in your code, put them into a README file!
their documentation and test suites. If you want different levels of functionality, you should split up your modules accordingly and make several distributions. Give away foo-base-1.3.2 to anyone who wants it, and charge extra for foo-bronze-1.3.2, foo-silver-1.3.2, and foo-gold-1.3.2, each of which contain a couple of modules that add still more functionality to the whole system.
That's the only reasonable approach if we want to establish a dependency verification system.
I think a lot of "version" problems can be solved by carefully organizing your modules so that blocks of functionality (barebones vs deluxe, informix vs sybase, etc.) correspond to modules or blocks of modules. Hell, this is just good solid software engineering practice,
Right. But this should be explained carefully in the manual for package developers!
Good point! I certainly hope we don't have to deal with this, i.e. have module developers worry whether their module will work with Python 1.5.2 or 1.6 or 1.6.1 (etc.).
We will have to consider this for binary distributions, because the binary APIs do change from version to version (not always, but sometimes). But since Python keeps a C API version number, all it takes is to note this version number in the package meta-data. At least for verification; distinguishing binary distributions for different Python versions by their file name is another question. But not really a difficult one, unless we want to support DOS file systems! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen writes:
At least for verification; distinguishing binary distributions for different Python versions by their file name is another question. But not really a difficult one, unless we want to support DOS file systems!
The package name should be stored in the package somehow, easily retrievable. There are probably a lot of NT boxes that use FAT file systems because they weren't born NT, and some companies deliver new NT boxes using FAT filesystems, and require that you explicitly convert the filesystem if you want NTFS. (DELL does this, and the conversion seems to have worked fine for me.) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Greg Ward wrote:
There have been a few rumbles about module version numbering on and off the list, and I thought I should bring it all out into the open. First, I think I tossed off a random opinion along these lines:
Module version numbers should follow the GNU standard: X.Y.Z, where X is the major version, Y is the minor version, and Z is the patch level. Alpha and beta versions can be noted by appending "aN" or "bN", where N is any integer.
Sounds ok. There should also be some way to name current snapshots that are not meant as official distribution, e.g. when I get bug reports I usually fix them and then put a pre-version on the server for the envolved people to download and test.
Now, there should also be semi-formal guidelines on what the different components of a version number *for modules* might mean:
* a major number of 0 means the module is still being actively developed and, while it may be ready for evaluation, nobody should depend on stability of interface or implementation * a change in the major number beyond 1 means a major change in the interface, possibly not backwards compatible with previous major releases * a change in the minor number means some new functionality has been added in a way that doesn't break the interface * a change in the patch level means bugs have been fixed without adding new functionality * an alpha version (X.Y.Z.aN) is an advance preview of a future release where the interface has not yet stabilized * a beta version (X.Y.Z.aN) is an advance preview of a future release where the interface has stabilized, but known bugs exist and are still being fixed
I don't think that a major version 0 does necessarily imply alpha status. Many Python extensions start their lifetime with 0.1 even though they could have started with 1.0 (I guess Pythoneers are attracted to understatement somehow). Likewise a change in the major number doesn't necessarily imply a change in the interface, e.g. a move from 0.9.9 to 1.0.0 may not include any changes at all. As a general rule I would not be too specific about the semantics of the version numbers: modules interdependence can safely be handled by comparing version numbers (a standard version number class would be a good idea, IMHO). The module authors will have to check compatibility anyway, so it's not the user's problem. Well, my 0.02e anyway... BTW: What's the general way of distributing subpackages ? My mxODBC stuff is getting a little "fat" and I'm thinking of splitting it up in smaller bits&pieces with a base package and n optional subpackages. -- Marc-Andre Lemburg Y2000: 386 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : ---------------------------------------------------------
M.-A. Lemburg wrote:
... I don't think that a major version 0 does necessarily imply alpha status. Many Python extensions start their lifetime with 0.1 even though they could have started with 1.0 (I guess Pythoneers are attracted to understatement somehow).
Likewise a change in the major number doesn't necessarily imply a change in the interface, e.g. a move from 0.9.9 to 1.0.0 may not include any changes at all. ...
Absolutely. When my mod_dav is ready, I'm going to change it from 0.9.x to 1.0.0. No API changes, no user functionality changes. It is bogus to have distutils try to proscribe rules of semantics to the version numbering. Cheers, -g -- Greg Stein, http://www.lyra.org/
Wow, looks like I found the hot-button issue that this SIG was looking for. Fun! Quoth Greg Stein, on 10 December 1998:
It is bogus to have distutils try to proscribe rules of semantics to the version numbering. ^^^^^^^^^
I think you meant "prescribe" not "proscribe". Whatever! Anyways, everyone who's howling in protest against forcing certain semantics down module developers' throats missed an important point: those were only *guidelines*, and what's more they were only *proposed* guidelines! (OK, OK, only Greg Stein howled. Andrew and Marc-Andre stated their case nicely.) Heck, you could even interpret the fact that "0.5a1" or "1.5.2a1" are "illogical" version numbers as flaws in my proposal, and come up with different guidelines that don't have that problem. Feel free! One possible modification to the guidelines based on the feedback received so far: "changes in major version number imply a change in the interface, *except* for the 0.9.x to 1.0 change." It would be good to stress that you really shouldn't break the interface in a "mature" (>= 1.0) product without bumping the major version number. The fact remains, though, that under my proposed version numbering system (which mandates syntax and suggests semantics), developers would be free to use version numbers however they like. The proposed semantics are *suggested guidelines*. How on earth could such things be enforced, anyways? (OK, here's an idea: if you upload version 1.3.2 to an archive, the archive software unpacks 1.3.2 next to 1.3.1, and makes sure that you haven't added any new methods or functions, or any parameters to existing methods or functions. JUST KIDDING!) My rationale for having some *suggested guidelines* is that most developers spend several years groping in the dark trying to figure out how to assign version numbers to their software. Experienced hackers eventually figure it out, and really smart, far-thinking hackers just "get it" immediately and come up with a system that will work for them henceforth and forevermore. I think most people, though, would benefit from a little friendly advice informed by the many decades of collective experience that will inform the "How to Develop and Distribute Python Modules" document that will come of all this. Greg also had a suggestion about loosening up the syntax, essentially by reducing it to a set of comparison rules:
1) a version number has 1 or more numbers separate by a period or by sequences of letters. If only periods, then these are compared left-to-right to determine an ordering. 2) sequences of letters are part of the tuple for comparison and are compared lexicographically 3) recognize the numeric components may have leading zeroes
As long as we can a) explain the syntax, and b) write code to parse and compare version numbers, then any proposal is valid. This one sounds valid. However, keep in mind that we're dealing with a much smaller and more cohesive population of existing packages than the guys at Red Hat deal with. It might turn out that a heck of a lot of existing Python module developers think there should be a standard (and fairly rigid) *syntax* for version numbers, and are willing to change their habits to go along with this. If not, we can adopt Greg's much looser syntax proposal, and if there's anybody left over who can't or won't fit their version numbers into that syntax... well, too bad. Greg (the other one) -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
... I think a lot of "version" problems can be solved by carefully organizing your modules so that blocks of functionality (barebones vs deluxe, informix vs sybase, etc.) correspond to modules or blocks of modules. Hell, this is just good solid software engineering practice, so you should be doing it that way anyways. That answer should also suffice where you have non-cross-platform source code (which is about the only reason I can think of for having platform-specific source releases).
People will use whatever practices they want. Many people do not have software engineering degrees (heck, many don't even have degrees!). If you organize distutils such that you require a change on their part, they'll simply ignore distutils. Back to .tar.gz files. I believe that you cannot attempt to enforce much policy on the coders. Some, sure. But pick your fights. -g -- Greg Stein, http://www.lyra.org/
Greg Stein writes:
People will use whatever practices they want. Many people do not have software engineering degrees (heck, many don't even have degrees!). If you organize distutils such that you require a change on their part, they'll simply ignore distutils. Back to .tar.gz files.
I don't think .tar.gz went anywhere. Are we supposed to be doing a new archive format as well? I don't see any point.
I believe that you cannot attempt to enforce much policy on the coders. Some, sure. But pick your fights.
Gosh, that's what we say about dealing with kids, too! ;-) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Fred L. Drake wrote:
Greg Stein writes:
People will use whatever practices they want. Many people do not have software engineering degrees (heck, many don't even have degrees!). If you organize distutils such that you require a change on their part, they'll simply ignore distutils. Back to .tar.gz files.
I don't think .tar.gz went anywhere. Are we supposed to be doing a new archive format as well? I don't see any point.
nah, I was trying to imply a simple archive of files, rather than a cool package. -- Greg Stein, http://www.lyra.org/
I think the discussion is moving in a wrong direction here. We should maybe start to rethink what the intent of version numbering is to start with: · A newer version should be recognizable by comparing it to an older one and this must be doable by both computers and humans · Newer versions might introduce interface changes, but these are described in the package history -- the version number may not reflect this change (e.g. Python's API level will change even though it's only a new patch level that's being released) So basically all that's needed is to be able to compare the version numbers of packages within a release sequence. It doesn't matter whether they use numbers and dots, words or dates. Trying to automate compatibility checks by only using version numbers isn't really a feasable approach, IMHO. This will always remain a manual and errorprone process... -- Marc-Andre Lemburg Y2000: 386 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : ---------------------------------------------------------
M.-A. Lemburg wrote:
... So basically all that's needed is to be able to compare the version numbers of packages within a release sequence. It doesn't matter whether they use numbers and dots, words or dates.
Trying to automate compatibility checks by only using version numbers isn't really a feasable approach, IMHO. This will always remain a manual and errorprone process...
I very much agree, which is why I posted my view on the rules we can use for comparing them. The code I posted returns tuples which should be directly comparable. I believe they define a good ordering, but it would also take a bit of review to see what happens when elements are inserted/removed (e.g. the a2 at the end of 1.5.2a2) -g -- Greg Stein, http://www.lyra.org/
participants (6)
-
Andrew M. Kuchling -
Fred L. Drake -
Greg Stein -
Greg Ward -
Konrad Hinsen -
M.-A. Lemburg