"Donovan Baarda" <[EMAIL PROTECTED]> writes:
> G'day again,
[...]
> You missed the "minor releases" bit in my post.
>
> major releases, ie 2.x -> 3.0, are for things that can break existing code.
> They change the API so that things that run on 2.x may not work with 3.x.
>
> minor releases, ie 2
On Thu, Mar 10, 2005, Donovan Baarda wrote:
>
> major releases, ie 2.x -> 3.0, are for things that can break existing code.
> They change the API so that things that run on 2.x may not work with 3.x.
>
> minor releases, ie 2.2.x ->2.3.0, are for things that cannot break existing
> code. They can e
G'day again,
From: "Michael Hudson" <[EMAIL PROTECTED]>
> "Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> >
> > Just my 2c;
> >
> > I don't mind new features in minor releases, provided they meet the
> > following two criteria;
> >
> > 1) Don't break the old API! The new features must be pure ext
Hear, hear!
> Going from
> 2.x.y to 2.x.y+1 shouldn't break anything, going from 2.x.y+1 to 2.x.y
> shouldn't break anything that doesn't whack into a bug in 2.x.y -- and
> "not having bool" isn't a bug in this sense.
Micro releases are all about bug fixes. Every micro release of the
same minor
On Wednesday 09 March 2005 23:53, Michael Hudson wrote:
> No no no! The point of what Anthony is saying, as I read it,
Your reading of my message is correct.
> is that
> experience suggests it is exactly this sort of change that should be
> avoided. Consider the case of Mac OS X 10.2 which c
On Wed, Mar 09, 2005, Michael Hudson wrote:
>
> No no no! The point of what Anthony is saying, as I read it, is that
> experience suggests it is exactly this sort of change that should be
> avoided. Consider the case of Mac OS X 10.2 which came with Python
> 2.2.0: this was pretty broken anyway b
