[Python-Dev] Those import related syntax errors again...

[Guido van Rossum]

>     Jeremy> The question, then, is whether some amount of incompatible
>     Jeremy> change is acceptable in the 2.1 release.  
> 
> I think of 2.1 as a minor release.  Minor releases generally equate in my
> mind with bug fixes, not significant functionality changes or potential
> compatibility problems.  I think many other people feel the same way.

Hm, I disagree.  Remember, back in the days of Python 1.x, we
introduced new stuff even with micro releases (1.5.2 had a lot of
stuff that 1.5.1 didn't).  My "feel" for Python version numbers these
days is that the major number only needs to be bumped for very serious
reasons.  We switched to 2.0 mostly for PR reasons, and I hope we can
stay at 2.x for a while.  Pure bugfix releases will have a 3rd
numbering level; in fact there will eventually be a 2.0.1 release that
fixes bugs only (including the GPL incompatibility bug in the
license!).  2.x versions can introduce new things.  We'll do our best
to keep old code from breaking unnecessarily, but I don't want our
success to stand in the way of progress, and I will allow some things
to break occasionally if it serves a valid purpose.  You may consider
this a break with tradition -- so be it.  If 2.1 really breaks too
much code, we will fix the policy for 2.2, and do our darndest to fix
the code in 2.1.1.

> Earlier this month I suggested that adopting a release numbering scheme
> similar to that used for the Linux kernel would be appropriate.

Please no!  Unless you make a living hacking Linux kernels, it's too
hard to remember which is odd and which is even, because it's too arbitrary.

> Perhaps it's not so much the details of the numbering as the
> up-front statement of something like, "version numbers like x.y
> where y is even represent stable releases" or, "backwards
> incompatibility will only be introduced when the major version
> number is incremented".  It's more that there is a statement about
> stability vs new features that serves as a published committment the
> user community can rely on.  After all the changes that made it into
> 2.0, I don't think anyone to have to address compatibility problems
> with 2.1.

I don't want to slide into version number inflation.  There's not
enough new in 2.1 to call it 3.0.

--Guido van Rossum (home page: http://www.python.org/~guido/)