At 11:14 10/12/98 -0500, Greg Ward wrote:

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!

It depends on your personal 'intuition'. I could say that an alpha version of a product is a _different_ product, in other words, the lexical ordering is: alpha/beta/production tag product name major version minor version subminor version In other words, if I am running 1.2.3 production, the latest release will NEVER be 1.2.4 alpha. That is a completely different product family! I don't run any alphas! But you are entitled to a different policy!

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.

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).

They can't. Just compare a JPython vs CPython version of something that also contains C/Java code. Smly: compare a MAC version of something whose Unix version assumes a command line.

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.

I'm not sure how to accomodate this one.

I have the idea for a general mechanism that will accomodate ALL the various 'dimensions'. I haven't implemented it yet, however. But I have made a crude start. I think one needs to assume arbitrary tags on components: some of which are standardised. For example: name: interscript interface: 1 implementation: 3.2 platform supported: Mac, NT, Unix python required: C1.5.1 included components: basic stability: beta languages: English, Spanish requires: name: mxTools interface: 1 implementation: >2 included components: delux

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.

You are right. But most filing systems don't have the require functionality: they're hieratchical, which is simply NOT good enough. This is also why version numbers in sequence like 1.2.3 are NOT enough. Heirarchies are not enough. More general categories are required. Interscript solves this problem by _generating_ code. This is the only way to cope with multi-factorial installation issues. This is also what 'autoconf' et-al do. BTW: a decision on _anything_, even with limitations, is better than no standard! Because there will always be limitations. But I think it is good practice to see how far we can push things, before backtracking to something we can agree on and implement, and which both clients and suppliers will find useful. ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia