[Python-Dev] Python 3.0.1

Michael Foord fuzzyman at voidspace.org.uk
Wed Jan 28 18:55:39 CET 2009


M.-A. Lemburg wrote:
> On 2009-01-27 22:19, Raymond Hettinger wrote:
>   
>> From: ""Martin v. Löwis"" <martin at v.loewis.de>
>>     
>>> Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
>>> it should be released earlier (else 3.0 looks fairly ridiculous).
>>>       
>> I think it should be released earlier and completely supplant 3.0
>> before more third-party developers spend time migrating code.
>> We needed 3.0 to get released so we could get the feedback
>> necessary to shake it out.  Now, it is time for it to fade into history
>> and take advantage of the lessons learned.
>>
>> The principles for the 2.x series don't really apply here.  In 2.x, there
>> was always a useful, stable, clean release already fielded and there
>> were tons of third-party apps that needed a slow rate of change.
>>
>> In contrast, 3.0 has a near zero installed user base (at least in terms
>> of being used in production).  It has very few migrated apps.  It is
>> not particularly clean and some of the work for it was incomplete
>> when it was released.
>>
>> My preference is to drop 3.0 entirely (no incompatable bugfix release)
>> and in early February release 3.1 as the real 3.x that migrators ought
>> to aim for and that won't have incompatable bugfix releases.  Then at
>> PyCon, we can have a real bug day and fix-up any chips in the paint.
>>
>> If 3.1 goes out right away, then it doesn't matter if 3.0 looks ridiculous.
>> All eyes go to the latest release.  Better to get this done before more
>> people download 3.0 to kick the tires.
>>     
>
> Why don't we just mark 3.0.x as experimental branch and keep updating/
> fixing things that were not sorted out for the 3.0.0 release ?! I think
> that's a fair approach, given that the only way to get field testing
> for new open-source software is to release early and often.
>
> A 3.1 release should then be the first stable release of the 3.x series
> and mark the start of the usual deprecation mechanisms we have
> in the 2.x series. Needless to say, that rushing 3.1 out now would
> only cause yet another experimental release... major releases do take
> time to stabilize.
>
>   
+1

I don't think we do users any favours by being cautious in removing / 
fixing things in the 3.0 releases.

Michael Foord

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




More information about the Python-Dev mailing list