We have a client who wants to upgrade their Sitecore site to the latest version. Well, normally that’s a simple “Sure, we can do it” but it’s not.
The reason is that Sitecore sometimes releases a version that's not tagged “recommended”. Sitecore will release a new version, even a totally new sub-version (6.1 or 6.2) but not call it recommended. Then, they have the release notes of what changed, improved, and fixed.
If I’m reading the release notes, I automatically gravitate to why not recommended those. The changes seems to be great such as a much improved Content Editor. I don’t know what Sitecore goes through to “recommend” a release. But, it’s hard for me to recommend a non-recommended version.
We try to get clients up to date with the releases but if it’s not recommended, we don’t recommend that version. So, we upgrade to the recommended version only. But, if the client finds out that there’s an issue with the recommended version that is resolved in later version, then we’re stuck hearing about it and eventually tell ‘em that we can upgrade them with the fix under warranty.
As you can see, it becomes bad business since we have to do the extra work without getting paid. Maybe it’s just the way I need to form the contract. Regardless of that, it’s still bad that additional work is needed later.
My main issue is that the non-recommended version number uses a mini-version number instead of the “revision” number. If it’s a patch, then it’s a patch and just send out a patch package not a whole Sitecore instance. I know that it may have warranted a new mini-version number because of the improvements, but I suggest that Sitecore separate fixes from improvements. Fixes can have revisions, while improvements (with the fixes of course) as a mini-version number.
What’s your take?