Pages

Wednesday, July 14, 2010

Release Time - SugarCRM 6.0

Although some folks I interact with are eager to upgrade, I generally recommend folks wait 3 - 4 months AFTER the initial release of ANY software package before considering it production ready. That statement has a tendency to draw some fire, as people like to point out that since SugarCRM itself has stated it is ready for use by the masses, it should be fine.

Allow me to explain my reasons, in hopes of also helping you avoid some headaches. First and foremost, let us define General Availability.

Within the software development world, a variety of labels are used to describe the state of a project. As a project matures, the label changes to indicate progress and achievement of specific milestones.

Were we to think of the development process as a spectrum, we would find that very young iterations of the software at one end, while versions considered ready for use by the general user community would be at the opposing end. The early iterations are typically named Alpha and those intended for production use are usually termed General Availability.

A large amount of testing usually occurs in between those two states, but it is unrealistic to expect ANY vendor to reach the General Availability state completely devoid of technical issues.

It is impossible for ANY vendor to account for any and all possible issues, even more so when the range of supported production environments is as varied as that of SugarCRM. Additionally, some issues can only be discovered by exposing the software to the wider range of environments with differing operating systems, data needs, customizations, integrations, hardware, etc.

Again, this is not a knock on SugarCRM (product or company), it is just the nature of the process and is true for ANY software and ANY vendor. If it were not, Maintenance Releases, Service Packs, Patches, Hotfixes and the like would not exist.

So, the practical definition of General Availability is as follows: SugarCRM has completed its development cycle for this version and testing has not revealed any issues within the software that could be considered a hindrance in production environments.

So why wait?

The latter part of the definition is an assessment based primarily on test scenarios within an environment where variables are more easily controlled. Out in the general user community, that is not quite the case, hence the reason why some issues are not uncovered until the masses start to use the product and expose the software to less controlled environments.

Waiting a while after the release gives you a buffer that permits you to learn from the experiences of others.

Issues that are common place with a particular version have a tendency to surface within a few days of release. Clearly, waiting several weeks gives one the advantage of learning potential solutions or release of patches that may address it, WITHOUT having to go through the headache of suffering the consequences the problem may cause.

This also helps underscore the importance of testing the upgrade in a development environment before deploying it into production, as well as making backups BEFORE upgrading your installation. Reverting to your previous version of the software could be quite the challenge without proper backups and not a situation you want to find yourself in should you encounter a serious problem after upgrading.

In a nutshell, do not volunteer to be the first to find the more obscure bugs because they are likely to be the most troublesome and they will impact your productivity.

5 comments:

Angel, thanks for the warning. I need to upgrade to 6.0 because of problems my ISP had preventing me from using 5.5. Now I'm manually grabbing tables out of my 5.2 db and re-importing them into 6.0. Hope I won't have further issues, but understand your note of caution on 6.0.Open to any suggestions on the data import, BTW.Glenn SchmelzleOttawa Canada

I don't recoment to use Sugar CRM sub-version 6.0.x - 6.1.x. because the methodology has changed a lot for everyday users of the system, I prefered to use sub-version 6.3.x - 6.4.x because its methodology are as equal as the sub-version 5.x.