Is 3.0 worth breaking backward compatibility?

[Lie Ryan]

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.

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. 

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).

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-
tag). 

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".