Version numbering (was Re: [Python-Dev] Python 1.6 timing)

[Jim Fulton]

Guido van Rossum wrote:
> 
> Andrew let me repost this mail of his to this list.  It's worth a
> discussion here (if not in a larger forum).  My responses are at the
> bottom.
> 
(snip)
> 
> There are several other things I can think of now that were planned
> for 1.6: revamped import, rich comparisons, revised coercions,
> parallel for loop (for i in L; j in M: ...), extended slicing for all
> sequences.  I've also been thinking about making classes be types (not
> as huge a change as you think, if you don't allow subclassing built-in
> types), and adding a built-in array type suitable for use by NumPy.
> I've also received a conservative GC patch that seems to be fairly
> easy to apply and has some of Tim Peters' blessing.
> 
> For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more
> conservative agenda, as suggested by Andrew: Unicode and distutils are
> probably the most important things to integrate.  (The import
> utilities are not ready for prime time in my opinion; there are too
> many issues.)

(snip)

What is the basis of the Python numbering scheme?

I thought that there was a notion that:

  - The first part changed with huge, possibly
    backward incompatible, changes,

  - The second part was for new functionality 
    
  - The third part was for bug fixes.

I thought I saw this scheme referenced somewhere and
possibly even attributed to Guido. (?) I think that 
this is a better scheme that what I've seen with 
the 1.5 releases.

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.