"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.2.x ->2.3.0, are for things that cannot break existing
> code. They can extend the API such that code for 2.3.x may not work on
> 2.2.x, but code that runs on 2.2.x must work on 2.3.x.
>
> micro releases, ie 2.2.1 ->2.2.2, are for bug fixes only. There can be no
> changes to the API, so that all code that runs on 2.2.2 should work with
> 2.2.1, barring the bugs fixed.
>
> The example you cited of adding bool was an extension to the API, and hence
> should have been a minor release, not a micro release.
>
> I just read the PEP-6, and it doesn't seem to use this terminology, or make
> this distinction... does something else do this anywhere? I thought this
> approach was common knowledge...
I see. You were proposing a much larger change to the way Python
releases work than I (and perhaps you? :) realised.
Not breaking any code 2.x to 2.x+1 is a nice idea, but doesn't really
seem feasible in practice.
Cheers,
mwh
--
nonono, while we're making wild conjectures about the behavior
of completely irrelevant tasks, we must not also make serious
mistakes, or the data might suddenly become statistically valid.
-- Erik Naggum, comp.lang.lisp
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
