3

The project that I am currently working on is using a library (well, sort of a library, it self-describes as a toolkit, Geant4), that is several versions out of date.

As there are bugs in it, that have been fixed in newer versions, its likely that it will be updated. I may not be asked to do it, but if I am, what's the best strategy, should an update be done all in one leap, or is it better to move forward one version at a time?

A single leap might go quicker, but then again the patch notes only document a step at a time. Is one less likely to get into trouble with incremental updates?

(if you feel that 'library' is the wrong term, feel free to edit)

Jekowl
  • 171
  • 4
  • possible duplicate of [When would you choose \*not\* to update a third-party library to a newer version?](http://programmers.stackexchange.com/questions/225217/when-would-you-choose-not-to-update-a-third-party-library-to-a-newer-version) – gnat Jul 07 '15 at 11:09
  • @gnat Not really. This doesn't ask if it should be done, its about how it should be done. – Jekowl Jul 07 '15 at 11:13
  • per my reading, [this answer](http://programmers.stackexchange.com/a/225252/31260) over there presents a fairly thorough analysis of your issue – gnat Jul 07 '15 at 11:15
  • @gnat They state that if you don't update regularly you may run into the issue I have. They don't advice either way one you have already encountered it. – Jekowl Jul 07 '15 at 11:18

3 Answers3

4

It depends if you have persistent state like a database or runtime configuration, and if you care about retaining that state. If you do, it's best to do the upgrade in steps, because this is how the developers test and support upgrades. Occasionally, developers will also support larger upgrades. Ubuntu's LTS versions are a good example.

If you don't have any state you care to retain, and you're already several versions behind, a "big leap" upgrade is usually cleanest, because the library developers have fixed bugs they introduced and improved interfaces they created in minor versions, but keep in mind that the longer you put it off, the more incompatibilities there will be in your client code. If you make the big upgrade and all of a sudden have a ton of bugs, you may want to back it out and do it incrementally.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
2

Small steps are usually useless in this kind of situation. More often than not, the real trouble (if there is any) stems from one particular change that causes you a lot of trouble, not from the accumulation of insignificant changes.

Therefore, doing things step by step will just take you longer to get to the critical point, and leave you less time to deal with it. A middling-large version step at infrequent intervals is usually faster than either tracking everything, or waiting until you no longe runderstand the API.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • I worked for a company that released hot fixes fairly regularly and due to some poor coding practices often introduced issues in a small release that would be fixed, yet again, by another small release a day or two later. They iterated up ever 10 releases. Ever since being in that situation, I felt it was better to go in with the latest version as incremental steps would be more frustrating and maybe more damaging. – Akira71 Jul 07 '15 at 12:35
1

Small steps will probably cost you more than one large jump.

Remember that for each upgrade of the library, you must perform regression testing (which is never cheap) in addition to relearning the API, and hunting down and fixing all the bugs that may pop up. Contrast this with doing one big jump. Regression testing, API familiarity and bug fixing are still there for the big jump but you do it once instead of twice or more.

Green
  • 269
  • 1
  • 5