[Distutils] Version numbers for module distributions

[John Skaller]

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