On 27 Jan 2009, at 23:56, Barry Warsaw wrote:
>> Also, 3.0 is a special case because it is IMO a broken release.
>> AFAICT, it is not in any distro yet. Hopefully, no one will keep
>> it around
>> and it will vanish silently.
>
> I stand by my opinion about the right way to do this. I also think
> that a 3.1 release 6 months after 3.0 is perfectly fine and serves
> our users just as well.
I'm lurking here, as I usually have nothing to contribute, but here's
my take on this:
<user>
I'm generally a Python 2.4 user, but have recently been able to tinker
in 2.6. I hope to be using 2.6 as my main language within a year. I
anticipate dropping all 2.4 projects within 5 years. We have not yet
dropped 2.3.
I didn't know 3.0 is considered a broken release, but teething
troubles are to be expected. Knowing this, I would be reluctant to
use 3.0.1, it sounds like too small a change. If you put a lot of
things into a minor point release you risk setting expectations about
future ones. From the 2.x series I 2.x.{y,y+1) to be seemless, but 2.
{x,x+1} to be more performant, include new features and potentially
break comlpex code.
I personally would see a 3.1 with C based IO support as being more
sensible than a 3.0.1 with lots of changes. I wouldn't worry about
3.x being seen as a dead duck, as you say it's not in wide use yet.
We trust you guys, if there's been big fixes there should be a big
version update. Broadcast what's been made better and it'll encourage
us to try it.
</user>
Matt
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4