Techniques for keeping your projects on the latest version

Question

I'm working on a new project and we're using a pretty nice stack. NHibernate, Spring, MVC... the list goes on.

One thing I've noticed tho is that in the 6 months since we've started we've had a new release of NHibernate, a new release of a third party control toolkit and Windows 7 is on the horizon.

We've had problems before where being stuck on an old version of a technology has cost us dearly, so I'm wondering what are some techniques we could use to help ensure that our transitions to the latest versions of things are as painless as possible?

Answer 1

Quite simply make it a priority and upgrade as you go along. If you keep up-to-date with the latest version, there will be less breaking changes than if you have to update 5 versions at a time.

Perhaps create a branch and do a test update to betas so that you are aware of forthcoming problems when that version RTMs (if using betas is a concern to you).

Answer 2

"update early, update often"

if you wait it will be more and more difficult so put high priority on updating the system. Developers mostly like to be on the bleeding edge so they will not mind too much, key challenge is to sell this idea to management.

It is always good to do step by step approach where you upgrade one by one tool. Then it is also easier if you need to roll back to older version. Big bang approach is more difficult and lots of things can go wrong.

Lets be realistic, every update will cost you time and also your team to do the switch to the new tooling version but after some time team learns to deal with it and level of stress when switching the versions is much less.

Answer 3

I agree with the other comments here about updating often. If you wait too long it will be enough work that you will notice it in the project productivity.

The way we do it is the following.

• One person on the team, gets the latest version, and makes sure that all tests run.
• That person the upgrades whatever dll's / tools are to be upgraded
• He also documents the upgrade.
• Build all code make necessary changes for it to build
• Run all tests, make sure they run.
• Manual smoke test of UI
• Send info to rest of team with doc of upgrade
• Checkin / make sure it builds on build server

This way we do not loose productivity of the team during the upgrade. Note this would be much more difficult without unit tests.

Answer 4

Speaking from a management point of view, don't upgrade unless there is a compelling reason. You have to look at what the upgrade brings to your project. If there are no benefits to the upgrade, don't do it. Obviously this isn't a hard and fast rule, but most teams I know don't have time to spend upgrading systems for no reason, they are too busy with feature requests and bug fixes. I recommend working in upgrades on the following basis:

1. The new version runs [significantly] faster or more efficiently and your customers/clients will see this improvement or it will reduce your immanent hardware needs.
2. Features have been added that you or your customers/clients want and can take [immediate] advantage of.
3. Security enhancement for a security flaw that affects your current or immediate future architecture.
4. License/support reasons. If you are at the end of your contract then you will probably want to make the final jump to the last version of the software that you are entitled to while you still have support for the upgrade. Alternately if you are on such an old version of the software that finding support documentation for it is difficult then upgrading is certainly called for.
5. Some aspect of the project that you are working on is directly impacted by the software that could be upgraded. If you are already going to be working with it and testing the functionality, it is probably a good time to upgrade and [probably] won't add significant load to the project.
6. Major changes. If your project or the software it relies on have undergone major changes then it is probably a good time to add the update(s) into your project plan. Major changes implies a more difficult upgrade path and should be persude on a scheduled basis rather than having to be shoe horned in at the last minute due to a needed fix or enhancement.

Specific reasons not to upgrade:

1. Software, installation, and regression testing costs money. Hence the need for a compelling reason to upgrade.
2. New software is often buggy or has unknown "features." For this reason many choose to stay one version behind the latest release.
3. Newer versions can often be slower than previous versions, this is especially true for small updates and patches.
4. Compatibility issues. Upgrades break things, it is better to skip as many incremental upgrades as possible in order to avoid updates that break compatibility, compatibility that may be fixed in the next update.

I recommend keeping a list of all software that your project utilizes along with their version and last upgrade date (along with other important information such as licensing info, support info, etc.). Evaluate every item on this list once a year in order to insure that you don't miss any updates that match a reason to upgrade that you may have missed. Software on this list with an old version/date and a newer version available may be incentive enough to convince management that an upgrade should be done.