Is 3.0 worth breaking backward compatibility?
benjamin.kaplan at case.edu
Tue Dec 9 23:25:59 CET 2008
On Tue, Dec 9, 2008 at 3:56 PM, Lie Ryan <lie.1296 at gmail.com> wrote:
> On Sun, 07 Dec 2008 21:48:46 +0000, Tim Rowe wrote:
> > 2008/12/7 walterbyrd <walterbyrd at iname.com>:
> >> IMO: breaking backward compatibility is a big deal, and should only be
> >> done when it is seriously needed.
> >> Also, IMO, most of, if not all, of the changes being made in 3.0 are
> >> debatable, at best. I can not think of anything that is being changed
> >> that was really a "show stopper" anyway.
> > But that's what a major release number does for you. Modula2 was quite a
> > break from Modula. Think of Python3.0 it as a new language, if you like,
> > that's inspired by Python2. You can stay with Python2 or you can adopt
> > the new language. That way you won't have to think of it in terms of
> > breaking any sort of backwards compatibility because there is no
> > backwards ;-)
> > --
> > Tim Rowe
> Actually I noticed a tendency from open-source projects to have slow
> increment of version number, while proprietary projects usually have big
> version numbers.
> Linux 2.x: 1991 Python 3.x.x: 1991. Apache 2.0: 1995. OpenOffice.org 3.0:
> acquired by Sun at 1999. GIMP 2.x: 1995. Wine 1.x: 1993.
Wine actually timed the 1.0 release to be at about t the 15th "birthday" of
> Compare with
> Windows: NT 3.1-NT 6.x: 1993. Visual Studio 97, 6.0, .NET, .NET
> 2003, .NET 2005, 2008: 1997. Photoshop (11 versions to CS4): 1987.
> Microsoft Office 3, 4, 95, 97, 2000, XP, 2003, 2007: 1990. Flash MX, 9,
> CS 1-4. iTunes 8: 2001. RealPlayer 4-11: 1995. Macintosh 1.0-9:
> 1984-2001, X.5: 2001. Winzip 12.0: early 1990s.
Just to note: Office 2007 is also known as Office 12, if you want to look at
version numbers. Also, Mac OS hasn't increased the major version number past
10 since they switched from their own proprietary kernel to using the
> Interestingly, many linux _distro_ also inhibit this quick version number
> change. Fedora 10, Ubuntu is 2 years old, version 8 (they start from
> version 6 not 1).
That's because 8 isn't the verison number- it's the year the version was
released (8.10 is October 2008, not the 10th update to version 8).
> Probably having higher version numbers sells better and looks more
> attractive (since it'd make it seem like the software is not a new
> product), having quick changing version number also makes users doesn't
> mind compatibility breaks. Also a pattern is that prop software often
> change how they version their product, (extreme example: visual studio:
> from using years, version number, .NET, .NET + Year, back to year).
> Changing how you version your product would make it "looks" like it's a
> fresh new product (boring ol' photoshop 9 looks fresh with the new CS-
> By having quick changing version number and often changing how product is
> versioned, vendors could also say: "its two/three major version away, we
> don't support that feature anymore since a veeery long time".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list