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?
Ironically I am doing it right now. Good part it is Saturday, and other developers do not know. Or they will lynch me..
<^>_<(ô ô)>_<^>
You should know who they are, what equipment they have, who is making who a favor (ie: who has to adapt to whom), and specially you should know what they want (such as how much backward compatibility).
At least if you are trying to support an Open Source solution, you have a chance of going back and fixing the old application to be conformant with new API's, etc. If you're running an old binary, you have no choice but to provide the old API's.
Hail Open Source, Death to binary only!
"To those who are overly cautious, everything is impossible. "
A properly designed OO system should alleviate all those backward's compatibility issues. And yes, in spite of all the /bots who complain about it, Java sure solves a lot of those OS/hardware compatibility problems...
Even if you are writing a minuscule app for your own use, that could not conceivably have any use for anyone else, you should always adhere to the following rules:
Denial isn't just a river in Italy
Bah, make the users conform to the developers, not the other way around!
-------------
Andy Tomaka
Abandoning backwards compatibility is often a controversial action, that needs to be carefully considered beforehand. Often, the best course of action is to consult with the Licensing Dept. They've been making great progress in the time it takes to reword licensing so that it is illegal for end users to attempt to use older hardware and/or software, often they can provide a solution in less than 3 months. This provides the Legal Dept. with a steady stream of secondary revenue, when they audit, and sometimes sue those users who call support hotlines. A win-win situation for all of us!
The two things I would say are, when you really reach the point where all the old crap is really clogging up the veins, fix it all at once. Make a clean break. Then people can at least keep in mind what is happening, what works with 2.x and what is still only for 1.x.
The other thing is, try to design to keep this from happening. Expose APIs that don't need to change much instead of the actual functions or objects that you use. One more level of indirection won't kill your performance in almost every case, but it will give you a whole lot more room to re-engineer when you decide you have to.
All that applies to the case where you control the interface and you need to change it. When you're publishing source code and want to decide what tools you can expect the user to have to make use of it, that's a marketing decision and not a technical one. You're talking about how many people will be excluded from your audience if you use GTK or assume a conformant C++ compiler. Technically the newer tools and libs are generally better, that's pretty clear. I think it's going to be a judgement call on the part of the developers as to how much they care about a lot of people being able to use their code. If they are willing to wait for the world to catch up before being able to use their program, then they can use the latest and greatest. If not, then they have to aim at a realistic profile.
When the architecture you're keeping backwards compatibility for no longer exists. (ie EMS/XMS in
WinDOS)
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?
Thats a rough rule at best - and one I often see flexed, and often flex myself - but 2 versions of any critical dependancy is often the accepted standard I see. In general it seems that for main stream applications it is reasonable to expect the user to be within 2 versions of the current latest version of whatever you're working on. It is reasonable to expect someone to be running at least - say - RedHat 5.x, or netscape 3 (IE 4 if you have the choice). Much beyond that and it seems that it is an unreasonable expectation of the user that the latest version of the software will work on their system. A hardware analogy is that at some point you just have to say, "I'm sorry 486SX_User_01, but this just isn't going to run on your system (at any decent speed)"
For dependancies like the compiler listed in the question, if it was available in said 2-previous-versions of the distribution it is a reasonable expectation.
Just my 46 Lira.
Ad in classifieds: Pandora's Box (no box) $5
I think there are several approach you may choose.
If you think your program/library has been widely adopted by many people, it would be very very hard to scrap the old one and start anew. You will provoke the wrath of other developers that use your program/library. If this is the case, then the possible compromise can be:
To do revamping, you'd probably want to look on how the Windows COM approach. I'd hate to say this, but this approach is generally good, but I don't know whether I can come up with a better solution.
Or alternatively do an OOP approach. OOP can help modularizing your code if it is done properly. (That's why KDE rocks)
That's my 2c, though.
--
Error 500: Internal sig error
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?
Each time we boot the computer it runs in 8086 mode... I get a dos prompt running in my 8086 at 1.4 GHz, with 256 mb extended mem. We need processors that are hardware compatible with athlons or PIIIs, not lower. Also removing the so many hardware legacy chipset functions might just need a small applet from bios emulating the legacy parts of a computer to use the dos mode. we'll end up with much cheaper solutions.. no?
Luckily open source doesn't have ot suffer from the issue as much since source availability ensures that old software can often be tweaked or sometimes just recompiled to make it work with new versions of dependent libraries.
How long to maintain backwards compatibility is really the question of your business domain. An in house app can probably be changed significantly without impacting many people while a widget library (like QT for example) must maintain backwards compatibility for at least a couple of minor versions. The ability to simply recompile old code after a major change in the library is a welcome feature too.
Your pizza just the way you ought to have it.
Look at USB 2.0
Free Unix? Free Windows. http://www.reactos.com
God created the universe in 6 days because He didn't have to worry about an installed base.
along the same lines, when do you give up support for browsers that can't render DHTML or CSS?
After a while your normally sensible and readable code becomes a nightmare spaghetti tangle of conditions, macros and multiple re-inventions of the wheel
this describes some of my javascript to handle multiple browsers to a tee
... when 5-year-old games still work.
Dork.
Let's step into this very medium of communication--the world wide web. All those webpages scattered about the web, code folded over code to assure that users of all variants are able to view a certain page. Page designers have to peruse the web in search of web browser documentation for not only different browsers, but different versions of different browsers. We have to worry about the peons still using version 4 of Internet Explorer and Netscape Communicator! Browser checking is a pain in the neck, and aside from this, IE and NS play the browser version hiding game, so checking their versions isn't a simple one, two, three.
I wish I knew the answer to when enough was enough, but I am at a loss. I will say, however, that I make my decisions of how far to go back in terms of versions by how much flexibility and usability the older versions offer. Anything less than version 4 of either Netscape or Internet Explorer offers very little in terms of flexible design.
But honestly, where do we set that limit? I don't think it's the best thing to do to say, "Conform or die!" If that's how things were, then the world would be swarming with Hitler's Nazis.
"You there! Cake or death!?" Uhh... death, no, no, I mean cake! "Ha, ha, you said death first!" I meant cake! "Oh, alright.. here's your cake. Thank you for playing Church of England, Cake or Death?"
nature is ancient, stop your rumbling, stop your rushing, and admire it once in a while
You might want to update your "facts"
FYI - Microsoft typically supports interop and upgrade from at least the two prior versions, possibly more depending on what the users are running. For example, even though XP is based on the NT codebase, MS supports upgrade from (and I believe interop with) Win98/Me.
Two rules of thumb:
1) Support whatever 90% of your users are using
2) Support the prior two versions
If you can't do the above, make a clean break and give it a new name or change the major version number and list the changes in the release notes.
If you have to make a clean break, if possible:
1) Provide a migration path
2) Provide an interop interface
And above all, listen to your users.
...... say 'fuck all' to backwards compatibility.
(put your head in the sand and mark me down as a troll if you want, but this is one of the HUGEST problems with Linux, especially Gnome)
Release a set of updates, only change the minor version number, break one critical function in each update, fix it and break a different critical function in the next. Repeat until users no longer depend on the functionality that you want to change, then introduce the new functionality.
;)
But first, go read "How to write bad code," and start following those suggestions too.
You kiss it goodbye when you hear about C#... another beautiful mess brought to you by MS...
1)Pull up your favorite cool beverage (preferably a six pack)
2)Use Python with your favorite OS any Linux variant
3)And share good times with 1 million user and growing forums.mtv411.com
It never ceases to amaze me how hypocritical some of you are. The guys here that are all for breaking backward compatibility are also the ones that complain endlessly when old DOS applications can not be run on Windows platforms. Why the double standards??
This is an argument in favor of Microsoft's interoperability and upgrade policies?
Isn't it ridiculous that you are happy with only the latest two version talking to each other?
Are you happy with paying MS full-price even if you are upgrading from Windows to a later version of Windows?
I have not met that many people who like to take it up their ass that bad, even if it is Bill Gates doing the fucking!
I thought it is a sign. ;-)
<^>_<(ô ô)>_<^>
Yeah, it's a bit harsh sometimes, but in the real world, if something is REALLY useful and necessary, people will do what they have to do to get and use it.
It's good to keep in mind older platforms, but there comes a time to cut off the dead weight. No matter where you draw that line, it's going to be tough for someone. Rather than making it too tough on the developer, or too harsh on the platform, I think the approach I've taken balances the two.
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
I like Microsoft's solution, which I'm sure was done somewhere else first. At any rate, here's the situation...
:)
:)
:)
Microsoft face the issue that they want to maintain backwards compatibility with everything, so they can leverage off the existing popularity of their platform. This means they can't let new libraries break old applications.
They had a problem once with MFC, where they updated its memory allocation scheme to make it more optimal. Problem was, a whole lot of old apps happened to work because they accessed memory incorrectly, but the old memory allocation scheme didn't reveal their bugs (I think they were doing buffer overruns, but the old scheme allocated a bit of extra room). Anyway, Microsoft released an updated MFC DLL, and suddenly old applications started breaking. It wasn't really MS' fault, but it was a big event, and I think it was the last time they touched old code like that!
Anyway, this is where they have their "DLL hell" problem too. Different apps are written against different versions of a DLL, many times with workarounds for known bugs in those DLLs. A new DLL comes along (installed by another application) and suddenly working applications start breaking.
So here comes COM. I've encountered it with DirectX, and it works like this. When you request something like a DirectDraw object or a DirectDrawSurface object, you also tell the class factory what *version* of the interface you want. Then you're provided with that actual implementation of the library. If you write your game against DirectX 2, but the user has DirectX 5, well your request to the DirectX DLL will actually give you the version 2 implementation! Which is cool, because if you worked around old bugs, those bugs are still there; they're not fixed for you!
As far as I know, you're not getting an "emulation" of the old implementation either; I'm pretty sure they just include binaries for each version of the interface. They could easily dynamically load whichever one you request.
Of course it means bloat, but there's no other solution. If you want backwards compatibility, you can't fake it, because it's all the really subtle things (like bugs that people worked around) that will bite you in the butt. It's been Microsoft's nemesis but its strength through the years, just as it has been Intel's too. Both companies need to remain backwards compatible with a *LOT* of stuff out there, and so they're forced to have all this legacy architecture. It would be nice to start from scratch, but then they'd be levelling the playing field, and that's no fun
Of course, this backwards compatibility drama affects everyone, not just Windows people. Just the other day someone installed a new PAM RPM on my Mandrake Linux. It installed fine, being a newer version, but some subtle change in behaviour meant I could no longer log into my own box. That's no fun either
- Brendan
No your quite obviously the FAG. must this continue?
Commit yourself to a strict policy: nothing in a minor version will break anything since the last major version. If your code is at 1.9.99, it should be backwards-compat with 1.0.0. If your code is at 1.1.0 and backwards compatability breaks, move it to a 2.0 release.
Typically, users expect breakage--or, at the very least, problems related to upgrades--with major versions. With minor versions, they don't expect breakage.
Follow the Law of Least Surprise. If you break backwards compatability, up the major by one.
Insofar as when to break backwards compatability, that's a much harder question. The obvious answer is a little philosophic: not all engineering problems can be solved by saying ``screw backwards compatability'', and some engineering problems cannot be solved without saying it.
The trick is learning which is which.
whatever..
A lot of the discussion seems to be related to issues of things like programming languages and operating systems (which are important). But what about keeping up with old formats and protocols? I think the issue is more one of what your project works with, than it is what language you choose (including the OS as part of the former).
I'm not so much looking for specific answers to the above questions, but rather, a general idea of how you think one should go about deciding those issues to come up with the best answers in some given situation.
now we need to go OSS in diesel cars
It's like we should still support the first T-Ford, allowing cars who run at 10mps on our highways.
I laugh when Linux people try sending fancy mail with just text-characters (no html fonts and no including of images within text to explain figures etc). Ok ok ok I like outlook :) (and i DO NOT care about viruses, they have never destroyed anything in my life)
Wait another 5 years before talking about backwards compatibility!
Is this post.
I'd also say that the key is managing expectations of your users. If you're in a commercial development environment, make sure you have plans in your first contract for what guarantees you will or will not provide for future forward compatibility.
And, if your major versions break key compatibilities, provide a migration path! That path can be packaged consulting, scripts that mangle / migrate data and code, whatever you can do to reduce the pain. That is, if you ever want to sell to those customers again...
But again, the best advice is just to listen to your users
Unless you're working one some free open-source thing. Then your users didn't pay you jack, and you're the programmer, so you know best, right?
Hey dickhead, the keyword in your excerpt was 'least'.
And it sounds like your the one taking it up the ass.
I feel that if you are developing commercially that it is your obligation to make things as easy for the END USER as possible... BUT!!! If you are developing for an open-source project and the like and are contributing to the PROGRESSION of the source...then code it right the first time and let someone else with more time on their hands and the NEED port it for bassackward compatability =) --Huck
"Just Smile and Nod." --Huck
I say screw backwards compatibility all together. Everyone wants to buy new computer parts, this just gives them a better excuse to do so. ;)
I believe that Backwards compatability should be handled at the OS level. MS could've easily ditched piled on Win16 and DOS support by just emulating it, applications could be signed for what types of systems it could run on, based on which libs were called, etc. (hopefully Hello World! should run on every machine. I wouldn't be surprised if a cout "Hello World!" made an XP box crash and burn) or maybe just signing it at the Makefile level.
Or something.
Non impediti ratione cogitationus.
Look at the web sites. Most of them no longer support any browser version less than 4.0 (be it IE or Netscape). I haven't heard complaints about that so far. Why? Because it gave them better web browsing experience, so they have upgraded. Consider this point for your own apps to see if it is worth to support older versions. Is there too many data? What about migration costs? There is no simple answer to this, and random answers (including this one) at slashdot may only confuse more than help.
¦ ©® ±
Software designed for Win2000 or XP won't run on 9x/ME. Likewise a copy of MS Word 6.0 can't read a .doc from Word 97 or 2000.
.doc format) will only run on XP? You either upgrade your office suite [b]and[/b] operating system or you stop receiving documents.
A nice side-effect (for MS anyway) is that this forces upgades if you want to be able to keep exchanging documents.
What happens when a new MSWord (w/new
The "facts" don't need updating. Just your interperetation of what the AC had to say.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Try telling that to Alanis ... she managed to sell a shitload of albums her misuse of ironic.
Code was ugly and hideous
Someone forked the tree a while back, and now we had to support 2 seperate source trees (this one was really annoying, because if fix a bug and change some behaviour in one side, since both sides had to be able to talk to each other, you'd have to introduce a corrosponding "fix" in the other side.
The core architecture was woefully outdated and ineficient
Speed was an issue, and the current architecture was limiting, and the code was optimized about as well as it could be (this was also part of the uglyness problem)
we were spending about 70% of our time fixing bugs in the old code, it took this much time because they were little and stupid and with the code in the state that it was in it took forever to trace things down.
Well, we had been wanting (desperately) to redesign from the ground up for a while, but the powers-that-be wouldn't give us the time, until one customer asked for a feature, marketing promised that they'd get it, and we said "Know what? We can't do that. Not with the current infrastructure." So the powers-that-be said "do what needs to be done!" and we said "yipee!".
Moral?
How much extra time is spent during debugging code that is due to the current state of the code?
How does the core architecture compare to what you will need in the future? Will it support everything?
How efficient is the old codebase, and how efficient does it need to be?
Can you get the time required to do so? This is a one-step-backwards before two-steps-ahead thing.
Do you trust the people that you are working with enough to be able to competantly and efficiently create the new architecture? This is a serious question, because I have worked with some people that are good if you tell them exactly what to do, but I wouldn't trust them to recreate everything.
Will you be required to keep the old codebase going while you are in the process of converting? If old customers need bug fixes, you might be forced to keep the old sourcebase around for a while.
Can you make the new design backwards compatible? If not, can you provide a wrapper of sorts, or some easy way to convert your customers from your old version to the new one?
If you are going to be redesigning the user interface or the API at all, then you must also think about the impact on your customers.
Just some food for thought.
If God gave us curiosity
A feature that exists in the major UNIX systems, but is not part of the standards, will majorly improve the performance of my project, and make it a lot easier to code up. Should I use it or not?
Of course the question is vague. I didn't state which systems and for a reason: I don't want to focus on the specifics (although I do have a specific case in mind), but rather, I want to focus on the general principle with this issue. Just how far should I go to make sure my program works on every damned UNIX out there? How much is important?
now we need to go OSS in diesel cars
The original AC says thanks, fam.
Why does every topic discussion have to turn into a anti-(insert favorite company to hate) bash?
:)
[this really should be off-topic, but this is the type of user complaint that you will get if you don't carefully coordinate with your users before breaking old functionality]
1) Software developers writing software for XP can write it so that it is compatible with 9x/me or even Win3.1 if they want.
2) The topic question was backwards compatibility. Very few applications (if any) are 100% forward compatible. If you save your Word 97/2k/xp doc in a Word 6.0 compatible format, Word 6.0 can read it just fine. Where is the logic in expecting Word 6 to read the native file format that contains new features in Word 2k?
3) How does it become Microsoft's problem when 3rd party application programmers don't design their software to run on multiple versions of the OS? (It is possible, in fact a large percentage of the win9x software runs on w2k without being *designed* for w2k.)
Think about it for a second, how do you make the application that you released last year so that it will be 100% compatible with the file format and the new features that you will dream up next year??? Even if the file format was compatible (which would probably make it a kludge), there is no way that the functionality would be compatible.
And, umm, you can always save in the previous version's file format.
How is this any different from the new perl script to configure IPchains that won't work on kernels prior to IPchains? Or any other added feature for that matter...this is a flaw in your expectation, not evil marketing.
Do you expect your Netscape 1.0 browser to be able to handle CSS??
I think the biggest thing to consider in how you revamp your code is...will the users stay loyal to you and update? For instance...Many Mac uses seem to be willing to make a big jump to OSX but there is the large risk that some apple users might jump ship. I know OSX will atrack many users as well but the added cost in advertising new features is yet another cost.
In some software cases, can you even aford to put your customers through any trouble at all?
csfacc@mac.com
Realistically, non-server software designed only for NT/2000/XP is 5 years out. It would be nice if Win98 went away with a snap of Bill Gates' fingers, but outlived it's mission by 4 years and isn't going to go away anytime soon.
[argument weak here - insert profanity]
Since when did Ask Slashdot become Answers from Cliff?
I can't spell or type, but that doesn't mean I'm unusually stupid.
I apologise for my my ignorance but just what is Unix 2?
Unix is Unix and Linux is pretty close but Unix 2 is something that I have heard mentioned various times recently but the actuality escapes me.
Developers, developers, developers, developers.
Do you expect your Netscape 1.0 browser to be able to handle CSS??
I'd expect my Netscape 1.0 browser to be able to view an HTML page that contains CSS, yes. The pages should still be perfectly usable without CSS (unless the designer is a complete incompetent).
Lets say you are developing an app that works with a certain set of data and it is stored one way.
With your new release (to 2.0, or whatever) that is a whole new work - you bundle tools to convert the old data.
MS does this with office, and people sometimes think its a pain, but I do not. If I'm getting a new version that (sometimes) works better, I don't mind running it through a filter - but make sure you don't make the mistake MS has made. Make sure this filter works.
If you're talking a new OS or other such projects - create data (read: settings) BACKUP tools. If you want the people to all migrate to this new OS, or large system application, give them a tool to backup those old settings and put the code right into you're new version to grab those old settings from the backup.
Thats all we want!
Get your Unix fortune now!
The only time you should *not* be backward-compatible is when you want to be embarassed.
If you are saying you can't make it as good as the old version, you are retarded. I don't mean that only as a jibe exclusively to Microsoft either - if you cannot meet the basic requirements of doing what the old version did, then you are as evil as a mojor vendor that decides to not support plugins.
"God is dead." - Frederik Nietzsche
Generally, however, old Netscape browsers will just crash on newer pages, even if the pages are 100% W3C standards-compliant. That's simply because they follow standards that the Netscape team never envisioned (and through some rather sloppy coding didn't properly prepare for).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
"Programming is like sex. Make one mistake and support it for the rest of your life."
1) Refactor early! Refactor the code and API as soon as you been suspect that it isn't going to be scalable/maintainable in the future. The longer you wait, the more unmaintainable the code gets and the more users will depend on your API. If a part of the API was a design mistake from the beginning, change it asap! Both you AND your users will benefit from the change (even though some will complain)
2) Make it "reasonable" backwards compatible. I.e. there is no reason behind supporting gcc-2.7-series. C++ compilers are lacking behind the ISO standard, but most are cathing up. Don't avoid exceptions because "some compilers doesn't support it". Some compilers doesn't, but exceptions has been around for 10 years! Time to force your users into an upgrade, I say.
-larsch
I will only say screaw backwords compatibilty durring beta, after that, I am sticking with the code until the next development cycle. Thats why I prefear to keep an application in beta much longer, I have more room to grow.
A lot of times it comes down to the application and how many changes are happening. If your making releases every week. You kinda need backwords compatiblity :) If its every few months, its sorta important, but not a requirement. If theres a release every year, screaw it :)
The size of the application also makes a big difference. Smaller project may not need to worry about it. Very large projects need to worry.
All in all, its not a "black and white thing", you won't find the answer in a text book. It depends on your goals, what your doing, the size of the project, etc etc etc. Every project is different.
until (succeed) try { again(); }
This is nonsense.
If those web designers would stop coding artsy-fartsy crap and stayed with simple formats there would be no problem even with archaic stuff like Mosaic
I am so tired of so called designers who go out of their way to press a flexible text presentatation system into their stupid little icon tricks. Pixel scale positioning - pfffft! Text as Images - pffft! Font sizes mandated by NaziStyleSheets - pffft pffft!
f.
Enthusiasm - I can make this baby fly!
Doubt - Something's not working here
Denial - Stating that legacy code should stay in place until the end of time.
:try_again
Anger - Showing signs of anger towards said legacy code.
Self-bargaining - Bargaining with one's self about what legacy code should stay and what should not.
Depression - Usually accompanied by guilt - When you realize you removed the wrong bit of code and checked it back in without reviewing the changes.
Acceptance - Re-writing most of the code since it's all buggered-up, anyhow.
Goto
The problem with M$ is not they always break something. The problem is that they break something and don't give a chance to fix it.
That's why open source exists for. If things get broken, then, there is a very high chance to fix things up if one has access to code and gets an idea of the new features, bugs and innovations. If a developer thinks he is doing right on going away from standards and practices, then let it be. He is the author and he knows best what he may want or not. However, he should care that the people, dependent of his creation (aka users), will have a chance to readapt. On open source, a developer may not have to worry too much on this, because, if his product is popular and he is a good guy, there will be other developers that may help to convert data or code to the new conditions.
On closed source, the developer himself should care to do this conversion. However, as we see, this is quite expensive in terms of resources and leads to the main bulk of the project going bloat and buggy. So, if you do care about innovation and stability do open source and keep the people coming to you.
Windows *98* outlived its mission in *97*?
Symbol Versioning
(This dummy line is added to get around a slashcode violation of postercomment compression filter - what the fuck is that?)
This is a confused discussion. A lot of people are mixing up "backward compatability for users" with "not making significant changes to the code base". The two are largely unrelated, except that screwing up the latter will also mess up the former.
What your user sees is, and always must be, decided by your requirements spec, not programmer whim. The only people who can get away with doing otherwise are those developing for their own interest (hobbyists, people involved in open source development, etc).
To put it bluntly, blanket statements like "meet 90% of your users' BC needs" are garbage. In many markets (notably the bespoke application development market) if you drop 10% of your users in the brown stuff, your contract is over, and your reputation may be damaged beyond repair. Look at MS; years later and in the face of much better libraries, MFC still survives, because people are still using it (including MS) and they daren't break it.
This is far removed from rewriting things significantly as far as the code goes, which is where things like the standards mentioned come into things. I'm sorry, Cliff, but you don't do this "when you can get away with it" if you're any good.
Every time you rewrite any major piece of code, "just to tidy things up", you run the risk of introducing bugs. You need to be pretty sure that your rewrite is
- necessary to meet your requirements, or
- fixing more than it breaks and not breaking anything unacceptable
or, preferably, both.If the rewrite is justified using these objective criteria, then you do it. When you do, you try to minimise the number of changes you make, and to keep the overall design clean. You retest everything that might conceivably have been broken, and you look very carefully at anything that didn't work -- it's quite possible that the people who originally wrote this code months or years ago made assumptions they forgot to document and you've broken them. Finally, if and only if your rewrite is performing acceptably and all the tests are done, you decide to keep it. If not, you throw it away and start rewriting again.
And for the record, yes, I spent most of last week rewriting a major section of our application, as a result of a code review with another team member. We kept the overall design, tweaked a few things within it, and rewrote most of the implementation. Now we need to retest it all, update all the docs, etc. This little exercise has cost our company thousands of pounds, but in this particular case it's justified by a needed performance increase and the significant reduction in bug count. But you can bet we thought very hard about it before we touched the keyboard.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If all you know how to do is "hack code" (as the Linux and OSS people like to say) and not design and program like a professional, then I guess the statement above is true. But for those of us who do know how to create first-class software backward compatibility is nothing more than a very minor challenge that's easily handled. I've been doing exactly this kind of programming work for 20 years, and the biggest problem I run into is untangling the horrible messes created by amateurs who are more interested in "getting it to work" than in making something robust, flexible, and easily maintained.
In a well modularized program, backwards compatibility is just another module in the architecture; it is not some anchor preventing forward progress like inexperienced slashdot posters would have you believe. Yes, there ARE in fact professionals out there making backward compatible software without breaking their backs doing it.
I work for a company where we have a multi-platform calendaring solution. Groupware type of thing. (And yes, we support Linux as well.)
While the Windows team was preparing drafts for an upcomming version, in the Mac team, we were readying a Carbon-compliant version of our product for Mac OS X.
The previous version was 5.1. This new, carbonized version didn't have any new features per say. A couple of bug fixes, and a new core API (Carbon). It was then numerated as 5.2. Basically, it's just a port of the 5.1 release, plus extra things to make it behave better under Mac OS X (AQUA stuff, and direct BSD networking instead of Open Transport).
The new 5.2 release supports Mac OS 8.6 and beyong, including Mac OS X. Prior to that, the 5.1 release supported System 7.1.2 on up.
The 5.2 release being a Mac OS X port (although it works under Mac OS 8.6 and up) meant that we could break away with System 7 without pissing too many users, since it didn't bring anything new in terms of functionality, since the 5.1 release.
The 5.2 release, therefore, acts as a cushion between the 5.1 release and the upcoming 6.0 which will most likely drop Mac OS 8.x, while be usable w/ Mac OS 9.x (and Mac OS X).
So far, this has worked OK for us.
A key to providing backward compatibility is "design intent"; i.e., closely examine the backwards compatibility issue when you are first thinking about creating a piece of software. Internal data structures, external file formats, APIs, etc. are all influenced by the design constraints placed upon a project. If one of those constraints is backward compatibility then these structures will all be built differently than in the case where no backward compatibility is ever required.
.MIF files influences coding decisions.
FrameMaker is a great example of an application that appears to have been architected from day one to provide backward compatibility: every version of FrameMaker imports and exports Maker Interchane Files (.MIF files) and so it is trivial to move files between releases of the application. While I'm sure this causes the developers some headaches from time to time, I know from personal experience that a constant anchor point like
Having done work on an ASCII interchange mechanism for a multiplatform application, I can be fairly certain that the FrameMaker decision isn't very difficult to implement: each release of the application has a pair of small functions, one to walk the internal data structure and emit the ASCII interchange format, and another that parses the ASCII interchange file and produces an internal data structure.
When we designed our application, the ASCII interchange functionality was deemed important; this influenced the internal data structures, which in turn influenced the binary data files. If we had tried to bolt backward compatibility on at a later date (i.e., in version 2.0) it could have been a lot of work; whereas, building it in from day one didn't cause any extra work.
Conscious design intent is the key to making backward compatibility a non-issue.
Finally.. something somewhat worthy of discussion.
Along the same lines... what *really* irks me is when I go to compile some utility I used a couple years ago... and I it wants a *whole bunch* of libraries it didn't need before, usually related to display only.
Too many good command-line apps get turned into huge, bloated GNOME apps for *no reason* (or just so the developer could play with gnome).
You shouldn't let backwards compatability hold you back, that's for sure. If you wanna bring out version 2.0, as a rewrite, why not? Keep the old one available to people, though.
ironic iron.ic /"I-'r@-nik also i-'r@-/, adjective [1576]
1) relating to, containing, or constituting irony
2) given to irony
synonym see SARCASTIC
-- iron.i.cal.ness /-ni-k&l-n&s/ noun
(C) 1997 by Merriam-Webster, Incorporated
iro.ny /'I-r&-nE also 'I(-&)r-nE/, noun [1502]
(plural -nies)
1) a pretense of ignorance and of willingness to learn from another assumed in order to make the other's false conceptions conspicuous by adroit questioning -- called also Socratic irony
2) (a) the use of words to express something other than and especially the opposite of the literal meaning (b) a usually humorous or sardonic literary style or form characterized by irony (c) an ironic expression or utterance
3) (a) (1) incongruity between the actual result of a sequence of events and the normal or expected result (2) an event or result marked by such incongruity (b) incongruity between a situation developed in a drama and the accompanying words or actions that is understood by the audience but not by the characters in the play -- called also dramatic irony, tragic irony
synonym see WIT [Latin ironia, from Greek eirOnia, from eirOn dissembler]
Meaning - I understsood the meaning of this - but not the person asking the question..
<^>_<(ô ô)>_<^>
First, I'm not sure if we're talking about code compatibility or user compatibility but I'll talk about code compatibility (who cares about users anyhow? :).
I've found that Java is a great lanaguage for making backwards compatibility easier. The main reason is that dynamic linking doesn't use cardinals or offsets. This means that I can fundamentally reprogram and entire class (even without using an interface) and still have a dependent program work fine with recompiling it. (Note: the only gotcha is finals, which are copied at compiliation to the dependent program - bah!).
Along with a couple of other things, such as using lots of interfaces and factories throughout the library, backward compatibility is hardly an issue at the code level.
Jason.
..I used my mouse to cut and paste copyrighted material. It is a circumvension device made by Microsoft. Can anybody say DMCA??
<^>_<(ô ô)>_<^>
Your web server should support all versions of HTTP. (You meant HTML?)
POP3 and IMAP4 are not 'new versions' of each other... neither is outdated. one is not a replacement for the other. Needs dictated solely by users.
Your web site should require no more funcionality than needed ot operate the way you want it to. That's just good programming. Don't use cookies or javascript or java if you don't need to.
You can stick to Unicode, because ISO-8859 maps into it properly.
Who is your target audience/market? That's where you get your answer. Nobody can tell you what to write, especially if we don't know what it is.
I don't think so...Software is all the same.
I've never seen even a smallish-application sized piece of Java code that would run 100% on all, of what? three?, of Sun's supported platforms....there are always platform dependent bug fixing (albeit not nearly as much as with C++). But combine this fact with Java's general pokiness and memory-appetite, and I'm afraid I can't see it as tremendous improvement over the current situation with our multiple Unix branches -- and can you imagine running an OS coded as much as possible in Java?
Maybe in time Java will work -- but I couldn't seriously consider Java for any major software project in it's present state. I'd rather see more effort put into a more unified and standardized Unix environment.
Not really, IBM on the mainframes and Intel on the 80X86 are the biggest backward compatibility stories around (over 20 years for Intel over 30 for IBM I would guess).
Why, without 16-bit mode and segmented memory, I'd..., uh -- never mind.
150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
When Microsoft attempted to remain completely backwards compatible, the public flamed them (anyone remember the famous 640k quote? Can't run on 8086 by surpassing it.) Microsoft remained vastly backward compatible when it released Windows 95, permitting it to run nearly all Windows 3.1 and DOS programs without issues, but placing huge stability holes in the OS to do so (direct hardware access by a common application is a no-no.) Backwards compatibility is not wholly a bad thing, but it can leave us mired in a place we do not want to be, sacrificing vast amounts of functionality to do so, and taking decades to undo it (Microsoft announced over 10 years ago that it would eventually merge all product lines to NT, finally realized now.)
There is a secondary issue, regarding work-arounds for small annoyances. Autoconf does a good job of taking care of this. For example, an autoconf macro in configure.in like this can be used to tell me whether I need to install an sstream header for old gcc versions, or if one is already installed. Sorry, had to snip it, because of the lame "lameness" filter.
One can check other conditions and define macros, or automatically edit Makefiles based on outcomes of this and similar tests. GNOME and KDE packages ship with a good collection of autoconf macros. I have found these very useful.
I test regularly on g++ versions 2.95 and up. Less frequently, I try to build against g++ 2.91xx. The compiler is portable, and using the same compiler makes life simpler. Even within this narrow framework, there are portability issues. For example, earlier gcc versions do not ship with the sstream header. The streams library is broken in early versions. For examploe, int is used instead of appropriate types. The best way to manage these subtle annoyances is to use autoconf. Libtool is also essential, for a different reason: the commands used to link vary wildly from platform to platform.
You never know the full set of requirements and constraints for any nontrivial project; what does help is to assume that you've got it wrong. That implies:
- Version information should be the first thing in any interface.
- Persistent formats are part of your interface (where persistent means "outliving a single invocation of a single executable" not "intended to be exposed to the user").
- Assume that every interface will be used. This implies that interfaces should made as few and as well-defined as you can get away with, for when you have to put in backward compatability layers.
- You can't know what your users want, because they don't know it themselves. But make sure you know who they are, so you'll know what you're breaking when you have to break things.
When the above is applied to developer interfaces, I'd also add:- You have to be cruel to be kind: when clients exceed your spec, die. Die hard; die fast; and leave a good-looking corpse (i.e., a clear error report.)
This is all a pain in the neck. There are tools that make some of it easier; e.g., some of the OO frameworks people have mentioned elsewhere include versioning facilities, if you think to use them. None of the tools handle the general design problem, though, and some are actively damaging in that they attempt to be as permissive as possible to the user, regardless of what this does to future compatibility efforts. Remembering that you've almost certainly got it wrong and you're going to have to fix it later can make it a lot easier to do that fix. And the next one.I've read some of what people had to say here, but it seems to me most people are missing the point.
For me the only reason to break backwards compatibility is "when you absolutely have to".
That usually means one of two things: there's something new I can't afford not to support (like the Linux kernel 2.4.x's new routing and firewalling goodies) or there's a new security bug fix that requires compatibility breaking.
"because MS (or any other company or person) wants me to" or "because new is better" are not strong enough reasons.
...what are the odds that the next version of CTOC will handle importing meeting requests sent from pure-Exchange sites to a CT/Exchange/CTOC site? And are we ever going to see an Entourage/Outlook-Mac version of the CTOC?
:)
(Sorry, couldn't help it...it was just a little too obvious who you work for.
News for Nerds. Stuff that Matters? Like hell.
Old code is hard to read - even if it is your code - because you lack the overall 'grasp' of what the code is doing - which the developer had had when it was written. Old code becomes just lines of code instead of part of an intelligent structure; you can see the 'trees' but the 'forest' has been lost.
This means that the problem with old code is that YOU don't know what the developers were doing; not that THE DEVELOPERS didn't know what they were doing!
It is a very easy mistake to confuse those two types of ignorance. Add in a little 'it can't be me that is wrong' attitude and the name of the game becomes a contemptuous 'out with the old in with the new.'
The truth is that there are differences in skill levels of programmers - old code written by good programmers is a lot better than new code written by poorer quality programers. If you didn't know that programmers differ in skill level it is conclusive proof that you are not a good programmer; to a bad programmer all code looks the same - that is why a bad programmer is a bad programmer
Wow! 10 miles per second? That's one fast model T!
In version 2 you are adding loads of features.
In version 3 you have oodles of software features and bugs that you are fixing and this is usually the most unstable bersion.
In version 4 you have stabalized version 3 and added more features, but the code is usually so bloated that it is difficult to maintain.
So version 5 you do a total rewrite and screw backward compatability.
ROTFLOL.. ok.. this is the mozilla model .. but I have seen this elsewhere too.
Seriously the best time to throw away backward compatiblity is when you cannot support it. I.E. Hardward to support it is not longer made, like VAX. Or when the percentage of clients that use your software that need the support is so small, that it is more of a burden to support it.
Only 'flamers' flame!
1. The developer may think their change is not significant enough to warrent a new version. When they are wrong, you have the same problem as before. Trying to avoid this would result in thousands of versions, and is better solved by statically linking.
2. The different versions still need to talk to underlying layers. Unless something like VMWare is used to run several copies of Windows at the same time, there is a layer where back compatability needs to be worked on. This could be solved by making a simple, well-defined lowest layer, but it is obvious that Windows (and anything in Unix designed after 1980) does not follow such design principles.
One think MicroSoft may be addressing is the obscurity of the Linux library versioning. I have been writing software for this for 8 years and I still have no idea what figures out what version of a library to use, or how it works. It would seem that the filenames are all that are needed to control it, but apparently that is not how it works. Nor do I know how to find out what version of a library a program wants (ldd prints the version it will load, which is not exactly the same).
Backwards compatibility is a necessary evil, but at some point you have to say that it time to move on. In my past I worked for companies that made Mac and Windows products. Both Apple and MS would give plenty of warnings that things are changing and to start getting ready. And still many would ignore the warning and whine that their product don't work with the new OS version. Solaris really needs to realize that its growing too fat trying to be backwards compatible for too many versions back. I remember at one UG meeting for a product I worked on it was about 1994 and Pentium and Windows and NT were the typical setup. A couple guys going nuclear because we had finally dropped support for DOS and 8088 CPU's. They wouldn't understand they got a decade of support, it is time to move forward.
Don't worry about it - nobody else does. Microsoft dosen't and they have been moderately successfull!. Today I took my 10-month old cell phone in for repair - the antenna broke off. They don't make that model anymore - so they gave me a newer (and better) phone. The one thing that should be done is to offer the user a painless upgrade path, automatically update any data or script files, give them simple "quick start" documents.
Often, dumping of B.C. is a sure sign that a newbie is in charge. (How many tried and tested routines REALLY need to be dumped in favor of newer ones?) Or that the people selling the code are trying to jack more dollars out of their customers. (Computers create text and pictures. How many REALLY innovative ways are there to present them?)
What's ridiculous is the amount of dollars and human effort expended in chasing the latest fashions.
What's appalling is the number of people who publish new software and don't even include the system requirements of the software -- and usually it's the latest -- because they are so suckered into the idea that newest is best.
REAL programmers burn to ROM. SMALL ROM. 'Cause the solution is so elegant and carefully tested. And the most outrageous claim of all: great code is optimized by human beings.
There, you puppies.
In the case where code is inhereted by a maintenance group or a successor developer, then it is more laziness than arrogance that tends toward the preference of tossing out existing code, as it is at times easier to reinvent than it is to reverse-engineer.
"Stop whining!" - Arnold, as Mr. Kimble
Sometimes the answer is not to target the newest implementation but the one that is used on all platforms in use. For Java this means sometimes going back to the 1.0 API! You lose a lot
of cool functions but it is the only way. Then just make sure it works best on the newest platforms or browsers depending if the program runs on an OS or a web browser. This isn't always an easy thing to find out. We made a web application using Java 1.1 and it turns out that Netscape on the Mac supported it without any of the changes from 1.0 to 1.1 so it didn't work there. But recently I've heard that Netscape may finally be supporting 1.1 for real on the mac and 1.3 with OS X. Cool!!! If only we wrote the program in Java 1.0 there would be no problems (except that it would probably be really clunky).
If you are coding a app to run on specific hardware (vertical app or black box), the choices are pretty easy. Make it perform the same functions . If it means a rewrite because of new hardware or lack thereof, do it.
If say, you want to be compatable with everybodys generic hardware, you can write specific compilers for them Example Sierra used a generic gaming system they wrote for most of the adventure games they made. It used its own language for describing the functions/graphics of the game. Provide a new game pak/art/music/etc, and viola - a new game. The game engine stayed the same (or very similar)
If both the hardware and software used is generic (compilers etc.) then design for the LCD (Least Common Denominator). This make a app more horizontal but can be run on a wide varity of systems and created with a wide variety of tools. Example: I just wrote a small tool to move cache files for my UT games. I wrote it in AWK because it was simple, and can be run on Linux/Windows/Mac/BSD/etc. Furthermore; it is more or less generic (all of you know AWK right?)
The one thing that breaks these rules is whiz-bang software. Eg UT Q3 Q4, cutting/bleeding edge technology. Mostly here you are trying to impress people or to make changes to something already, in hopes that it will be the next generation of generic tools/hardware. This is almost the first case (black box) because it will have lots of bugs, may be cranky as hell, and nasty to code.
Don;t get me wrong, compatability is good, but you have to ask yourself - "Just who is this for?"
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
Solid proof we have not progressed - bring back the model T, Ford!
Use ISO 8601 dates [YYYY-MM-DD]
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.
Never ever ever.
Embedded systems that have a defined FINITE range of functionality of course should only deal with what they can encounter.
But you should NEVER break existing functionality.
I believe Microsoft has a patent on that technique, anyhow.
and don't bother with backward compatability. I can't count the number of times I've downloaded some nifty/cool software from freshmeat to find that nearly half of my system libraries need to be updated. That wouldn't be so bad if the OS release I was running were say - 6 months old. However that's not the case - SuSE/RH could have made the realease yesterday, and I'd still have the same problem!
I think we need more backward compatability and less interdependencies - not the other way around.
...as a side effect of Win 9x relying heavily on DOS, some parts of its code assume you are running on a 4044 chip.
I do not have a second account and my Karma is 8 now (after ~600 posts in several years). It will be 7 now: Fuck you, anonymous asshole.
<^>_<(ô ô)>_<^>
Usually in a discussion like this it is good to define the terms. Many of the times people say Backwards Compatibility when they mean forwards. Forward Compatibility - being able to run new apps on old boxes. Backward Compatibility- being able to run old code on new boxes.
The city is being overrun by a herd of Lucy Liu's.
1. You have to distinguish backward compatibility in the program or in the interface presented to the users. Sometimes, the latter can be preserved for the sake of the clients while the former can be invisibly improved to adhere to current standards.
2. Cross platform portability is a good thing in its right. Not just be cause you can increase the market by a few percent, but because, in my experience, the more a code has been required to run throught the gauntlet of different compilers on different platforms, the more likely the code is not going to break. That means break, period, as well as not break when porting to platform n+1.
Maintainability and extendability of software is improved markedly if you make an effort to be cross platform portable.
That's not to say that you need to port back to the same least common denominator as Ghostscript has been known to do. While impressive, I consider that level of effort to be more than I would consider for a software project. But a lot of that is legacy anyway.
I work a large C++ Solaris project that has code from the mid-1990's when compilers didn't have as much of the standard as they do now. We're slowly making an effort to move in the direction of standards in this regard because it will decrease long term maintenance costs and make the code base easier to read and, therefor, to extend.
"Provided by the management for your protection."