Slashdot Mirror
When Do You Kiss Backwards Compatibility Goodbye?
Arandir asks: "Backwards compatibility is great for users. But it sucks for developers. After a while your normally sensible and readable code becomes a nightmare spaghetti tangle of conditions, macros and multiple reinventions of the wheel. Eventually you have to kiss off backwards compatibility as more trouble than it's worth. The question is, when? Should my code conform to POSIX.1 or Single UNIX 2? Should I expect the user to have a ISO Standard C++ compiler? What about those users with SunOS-4.1.4, Slackware-3.2, and FreeBSD-2.2?" This question is really kind of difficult to answer in the general sense. The best advice one can give, of course, is "when you can get away with it". Not much help, that, but the lost of backwards compatibility, like most complex decisions, depends on a lot of factors. The key factor in most developers eyes, of course, is the bottom line. Have many of you been faced with this decision? What logic did you use to come to your decision and what suggestions do you have for others who might find themself in this predicament?
I think I like Apple's backwards compatibility, but it's not making one app backwards compatible,
For instance, when they migrated to the PPC architecture, they made apps that ran on both platforms and older OSes, then capped development and froze the older version at whatever version number, then developed for newer machines. The rest of the apps followed, like AOL 2.7 is AOL's last 68k release, they just developed only for PPC since then, although apps like Opera still make a 68k version alongside a PPC version.
Of course, you need to know your users, Will they be satisfied with a frozen and version capped release, provided there are no bugs?
This is the story of my app, Kinkatta ( http://kinaktta.sourceforge.net/ ). It originally was a QT only app and only recently did it move over to utilizing KDE. But that in itself isn't exactly what this is about so I will talk about the more spisific case. From .25 to .91 today we have gone through I believe 4 different formats in which we save our settings, buddylists and so forth. In each of the changes we had to add some code to convert it over. The best solution we found is to know our users and make sure they know about us. What I mean about that is that we only support the previous settings format and make sure everyone uses it. Kinkatta's users are kept informated when a new release is out through a number of ways. We then keep that format for as long as it takes for us to be sure that 99% of the users are using that format. One of the nice things incorperated into kinkatta is the auto-check feature. On login it will goto the webpage and see if there is a new version and if there is then it will tell the user. This prompts them to stay up with the new releases much more then if the feature was not there (and yes you can disable it). Do to the gpl/lgpl nature of the app people will upgrade more often and are unlikly to stay with version 0.64.1 This is a true plus point for the open source. Because of it we havn't had to worry about users who don't want to pay the 29.95 for the new version.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
Oddly enough, when Altavista first came online, I used it frequently for trying to resolve DLL conflicts. Probably more than I used it for anything else.
:)
Sad to think that I can now find just about anything on the internet, and it all started because I had to support Windows 3.x.
But it is nice to think that I was running Linux as my primary box in my office in 1995, using lynx to browse as I debugged my new Windows 95 installation on my other box.
Just food for thought for the younger admins out there: DLL hell was the largest part of my job at many sites. Believe it or not, it has gotten much better in recent years. Think of video drivers messing up fax software, network drivers killing the accounting package, and video conferencing software killing the spreadsheet program. As sick as it sounds, Win 9x is a dream to support by comparison.
4:30 in the morning, I must be getting delusional.
So you're claiming Microsoft is making a mistake by providing backwards compatibility for DOS, but "open source," whose primary operating systems are Linux and FreeBSD, both designed to be backwards-compatible with 1970s UNIX systems, are somehow not?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
The API has barely changed in the last 25 years. A friend of mine has an application that's been running unchanged since the 1970s. It has contined to work across generations of hardware. And it's in assembler.
They had the advantage that their OS was decades ahead of its time. UNIVAC had symmetrical multiprocessing with threads in a protected mode environment thirty years ago.. And threads were designed in, not bolted on like UNIX.