Different attitudes towards upgrading and developing software
So many times, even in the last few days, I have talked about keeping software up-to-date. For many people that means upgrading to the latest version of windows as soon as it comes out, or Office, or well… fill in the blank. It’s a vicious cycle when you think about it. So, is it necessary to REALLY chase the absolute newest version of anything that you use. The best answer is “it depends”.
There are a couple of competing interests in designing software. The first is adding features. This usually catches marketings attention because there are new things they can sell about the product. The second interest is fixing bugs. Some of this may be big and noticable, like display problems within the program or other unexpected behavior. Some of this are big and unnoticable like security vulnerabilities. They might lurk unknown for years, or be exploited and STILL not noticed. There are also little insignificant bugs. “You mis-spelled the “spelcheck” option in the menu”.
Most open source projects have what’s called a “stable” branch of development and an “unstable” branch. That’s essentially saying stable is what is currently out in the wild. For that branch they usually focus on fixing bugs. No new features are really contemplated unless they can EASILY be added without bringing in lots of problems (new bugs.) Unstable is the area where things get played around with. New features are introduced, things break badly sometimes. As the new featuresets stabilize, a new release is considered and you have a new stable branch. The old stable branch is sometimes maintained for serious (security) bugs, the new stable branch is recommended to be installed and used and the code is forked to a new unstable area where future new features get toyed with.
Most of software development follows a numbering scheme to reflect BIG changes and little changes. Those BIG changes are usually feature additions, the little changes are bug fixes. In software numbering you might see “version 1.0” or version “1.4” or “version 2.0″…. the idea here is Big changes are reflected by the number before the . and little changes in teh second number. For this reason 1.0 is usually thought of as a first release, 1.1 as a “fix” there may be many small fixes (1.2, 1.3, 1.4,….. 1.12, 1.13) before a new feature set is added and the changes are significant enough to be considered 2.0
About the time of Windows 95, Microsoft abandoned traditional version numbering and went for release year. In some ways this is frustrating as it can mask what updates have been applied. But with the XP line (and older NT line as well) , big updates are bundled into Service Packs (current is Service Pack 2 for XP).
So, here’s my rule of thumb. Incremental (bug fix) updates are a must, so Service Packs are in that category, upgrades from version 1.1 to 1.2 are in that category. Big updates are the “maybes”. Let’s take the ezcontents example. There was a major problem that seems to affect ALL versions prior to 2.04, that’s a good sign that we should go ahead and update, even from an older 1.x version. When upgrading major program versions (1 to 2, 1998 to 2000), it’s worth evaluating the feature benefits, the availability of fixes for the new version (all those new features may bring new bugs) and the support commitment to maintaining the old version with security fixes. Sometimes it’s tough to weigh all of those, but there are times when you look at the big picture and decide to stay with what you’re using until the new version is more settled. (Or because it’s serving it’s purpose and has no major problems.)