Should I update an application when a used framework release a new version?

Question

I have an application that use several libraries and frameworks, should I update my application to use the latest version of those frameworks when a new stable version is available?

For example, migrate from python 2.x to python 3.x, or from spring 2.5 to spring 3.0, but the question es very general, not language specific.

If I keep the application updated to use the latest stable frameworks versions then I will have new features available in case I need them.

If I don't, then may be in a future I will need to do the update and it will be a lot of work to update the application.

Is there any best practice about this?

Answer 1

I would. Here's why. If you don't then the set of libraries you use becomes out of date. At some stage you have to upgrade one (due to a bug fix), and at that point you have to upgrade several, due to intercompatibilities. A simple library upgrade thus cascades.

My approach is to upgrade regularly, but not immediately - simply when time allows. That way you can move your library set forward gradually, with a timescale that you set yourself. Any incompatibilities are dealt with one library at a time rather than having to cope with a whole set of problems just when you want to resolve a problem by upgrading one library.

Answer 2

You must put things in the scale.....

1.-do you get any advantages

2.-will it make you suffer

3.-will it break the workflow at your company; how much dead time will be

for myself... I like to have the latest technologies... this means less bugs and more learning =P

Answer 3

This is a very common problem. The solution may not be so cut and dried. It depends on how you intend to support your application. Based on your question, I get the feeling that you have long term goals for this project. In that case, then you would be well advised to upgrade to the latest version.

However, if the older version is well established, like the case with Python 2.x, you will continue to get support for some time after the new version comes out. But don't delay the inevitable.

Answer 4

It depends on the framework/library. If the framework is popular, well supported, well documented and quite stable (such as Spring) I would definitely upgrade - you get all all sort of bug fixes in existing functionality and some new functionality.

Frameworks that are not as popular/well maintained I would be a bit more careful.

Anyway, I think the default should be to update - As you said, it is easier to do things in small steps. When you defer updates you are creating a headache for yourself: at some point you will have to update but then the gap will be so huge that updating will be practically impossible. You'll get stuck with a version that is no longer supported.

Answer 5

If I keep the application updated to use the latest stable frameworks versions then I will have new features available in case I need them.

This is the essence of premature optimization.

If I don't, then may be in a future I will need to do the update and it will be a lot of work to update the application.

Do you get any benefit out of doing it in lockstep with your library provider? If so, update in step with them. Otherwise evaluate the changes just like you would any feature change in your application and update when it makes sense.

Answer 6

Based on experience, I prefer to take a very conservative approach to this.

Updating components or frameworks can be risky at any time. You may find new bugs in the framework, or you may show up bugs in your own code due to assumptions made about the old framework, or due to work-arounds you may have had in place.

In general you shouldn't update to the latest just for the sake of it, unless there are new features or bug fixes you want to take advantage of immediately, or maybe you just have a lot of time on your hands! Updating frameworkks can mean a lot of retesting, just to make sure everything works okay.

The only time you should update immediately is when the version of the framework you rely upon is out of your control and the client is likely to do the upgrade. An example of this is Internet Explorer - if i have some features that rely on v7, but v8 has been released and the behaviour of that feature has changed, then i need to upgrade immediately, as the client will upgrade at any time. As an example of the opposite, if i have an app that relies upon the .Net 2.0 framework, i shouldn't recompile against the 3.5 framework just for the sake of it, because the two versions of the framework live happily side by side, so upgrading (theoretically) can produce issues that I didn't need to introduce.

Answer 7

How longs is a piece of string?

Your general question can only have a general answer. And the answer is probably how you feel about the risk/reward ratio in any given set of circumstances.

Large IT departments tend not to roll out the newest Windows immediately (I doubt that many companies currently use windows 7 across the board, and many stil use XP (think VIsta)). They may not quite skip a while release, but a general rule of thumb in windows IT is to wait for service pack 1.

For apps & frameworks - yes, there might be some great new features, but do you need them? And do you have time to implement them and do you accept that your new code won't be bug free at first?

Otoh, the new release will probably have bug fixes - seems good, but are they bugs that your users are reporting? If not, why bother ("fixes clicking close/then cancel crash when using the Chzeck version of the frameework on a Bulgarian version of windows"). And with the bug fixes the new release will have new bugs.

Risk/reward - what's your reward? Can you sell a new version of your app and make more money? WHat's your risk? Loss of reputation if new version is buggy, support time (and costs).

How long is your particular piece of string?