[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2

Kurt B. Kaiser kbk at shore.net
Sat Mar 12 21:35:21 CET 2005


"Martin v. Löwis" <martin at v.loewis.de> writes:

> Kurt B. Kaiser wrote:
>> To eliminate this confusion I'd propose either 1. Eliminating the
>> separate IDLE versioning now that it's installed with Python when
>> Tcl/Tk is available.  or 2. Bringing its version in sync with
>> Python 2.5.  I'm in favor of the latter, to handle the situation
>> where a customized IDLE is decoupled from Python.
>
> I think there is a 3rd option:
>
> 3. Decouple Python and IDLE version numbers. I.e. IDLE version numbers
>     should change only when the IDLE maintainer thinks they should, not
>     when the Python release manager bumps the Python versions.
>
> For 2.4.1, the IDLE version number should just be rolled back (or
> forward) to "1.1.1". Unless you plan to include IDLE 1.1.2 with Python
> 2.4.2, it will stay at 1.1.1 in the 2.4 branch.

Well, I had to read this several times to understand it :-)

While your third approach makes some sense, I believe it's actually the
source of the current confusion.  IMHO it would be better to bump the
micro number to agree with Python's, and have an empty entry in the
IDLE NEWS.txt.  We tried your suggestion with 2.3 and it got confusing.

Part of the problem is, who bumps idlever.py and the header in NEWS.txt?
Anthony and I have been stepping on each other a bit.

My suggestion: IDLE maintainer starts the new NEWS.txt header if 
Python release mgr hasn't, but leaves it

"What's New in IDLE"     i.e. no release number

and lets the release manager handle the release numbers.



I still prefer making IDLE's version the same as Python's.

> Whether or not updating the IDLE code base to include new features
> is another issue - it might be that an exception can be made for IDLE;
> OTOH, it might be reasonable to apply the same strict requirements
> for idlelib as we do for the rest of the Python library, i.e. no new
> features.

I've always taken that approach: only bug fixes on the maintainance
branches.

-- 
KBK


More information about the Python-Dev mailing list