Upgrade to What?

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?

I’m Back

Okay, it’s been a while (specifically almost a year) that I’ve written something on Sitecore.  Since the economy wasn’t too good last year (even now), I had to focus my efforts on ensuring my company is not affected much.  I needed to redirect my attention to growth and to do that is to have the right people in place.  I think I have that now.  I’m still going to be busy doing that, but I’ll put more time into my Sitecore blog.

This may be a year later but Sitecore’s Security UIs have remained the same, so I thought I pick it back up from where I last left off. 

There are five (5) security-related UI's in Sitecore (not counting the security tab/section on the Content Manager):

• Access Viewer
• User Manager
• Security Manager
• Role Manager
• Domain Manager

Sitecore’s Access Viewer is certainly much improved from previous versions.  It used to be somewhat confusing but with the context help/explanation on the right, it makes it easier to understand.  Notice also that you can now also see how workflow affects security.  It’s brilliant. 

FUTURE FEATURE: To make it better, it’d be nice to see how the security is inherited such as if this is from the template, or from a hierarchy, or combination.  This way, we can easily diagnose potential security issues.