I am just developing my first EE site for payment. I manage all the other sites I have ever built, but this one will be handed over to the client.
So how do other developers handle updates of the EE installation?
Do you price in X many updates or charge per update or an annual management fee?

I am looking at doing more sites for clients and like EE, but this seems like it might be a problem given the number of build updates there are.

As of yet I’ve not yet charged for updates but I’ve been considering it. I saw a thread a while back (should’ve book marked it) about updating EE through SSH in which the process of updating as was simple. I’ll have to search for that thread. If I find it I’ll post it here.

Unless it’s a security issue, generally I wouldn’t upgrade a site unless the client has asked for a feature that is included with the version newer than the one they have. If it ain’t broke…

Found it: SSH & the Amazing 60-Second Upgrade

the_butcher has a good point. You don’t know how the new version will affect the live site. But if you “have” to upgrade the site you should to duplicate the site on a test server, something set up similarly to your live configuration (as close as you can get). Test the site out on that test server to see if you’ve broken anything with the upgrade.

But back to your question I think it’s reason able to charge clients for upgrading the EE software. If the client asks for the upgrade for specific features available in the newer version then charge for it. If you’re performing the update to solve an issue with the site based on the way it’s coded or a server issue I personally wouldn’t because I look at that as my responsibility.

I was thinking that build updates are often fixing things that didn’t work properly in the first place or a security hole that needs plugging, so they should be done ASAP.

But I can see that updating could be a problem if they have changed things without your knowledge.

Would/should you supply the link to build updates so that the client can update if they have the technical skills to do it.

If they feel comfortable running an upgrade, sure… after all that’s more chargeable work if they muck it up ;]

Most times a build update only has minor fixes and usually doesn’t contain any features. If there is a major security fix this is noted all over the site (news, blog, and if its really big, email to all customers). Our security track record is excellent so security updates are rare.

Generally speaking unless a build addresses a problem your client is experiencing there is no reason to update to every new build.

I would recommend, though, subscribing to the Build Forum feed.  Sometimes major issues are handled in build releases, that could impact sites.  On a maintenance level, this is rare, but is especially true in the weeks that follow a new version release.  It is inevitable that some issues with a new version will not be discovered until it is running in a variety of environments and types of sites, and in these cases we prefer a quick turn-around on these bug fixes without necessitating a new point release.  Either way, subscribing to the Build Forum feed will let you know what changes have been made, and you can make a decision on whether or not to update.

I know for our organization, if we are still actively working with the client we provide regular updates, but not for every build. If we are no longer working with the client, we provide notice of major changes or builds that fix bugs we had to work around; then let them know that we can update if they like.

We always check new releases on a personal site first, though that’s no guarantee that something won’t break on a client sites. I’ve found the easiest way to manage that is to schedule upgrades on Friday evenings, and have Friday, Saturday, and even Sunday if necessary to check through the client site. To that regard, for each client site, in the notes field, I general keep a list of ‘trouble’ areas—areas with custom PHP, queries, multiple embedded if elseif statements, etc.  If the client site is large, I’ll abandon notes and actually install a weblog called ‘sysadmin’ which only super admins have access to. I then file notes about ‘worrisome’ code that currently works but might break, and other details—including data on all upgrades—build or otherwise.

I also consider providing updates as part of the service we provide, we also do automatic service renewal with EE for them, so long as they are active clients. Also, I try to be relaxed about it. I’m never like we need to upgrade these 10 clients this weekend. Build can happen within a week to 2-3 months later. Release upgrades, are scheduled a bit more, but still, we mostly do 1 or 2 updates at a time.

Tip: Keep notes on each client. Back in my web dev days I’d had clients I hadn’t heard from in 8 months call me up asking for updates, etc… and it was super useful to pull up a note with any customizations, plugins, etc… I’d done for that client.

Leslie Camacho - 13 September 2007 05:38 PM

Tip: Keep notes on each client. Back in my web dev days I’d had clients I hadn’t heard from in 8 months call me up asking for updates, etc… and it was super useful to pull up a note with any customizations, plugins, etc… I’d done for that client.

I’ve found the notepad in the EE CP works well for this.  I’ve also started to use the template notes for this purpose when a specific template is more involved.

I’ve found the notepad in the EE CP works well for this

In a couple of cases I’ve created a “dev” weblog within the site where I keep track of what I’ve done and how things work.

We provide build updates as needed, and version updates within 30 days or release as part of our basic service package.

We also keep a .txt (text file) in each hosting account called aaUpdateNotes.txt. In it we document all the add-ons, hacks, and other things we’ll need to know when updating a site. We’re now servicing around 100 EE sites, and you just can’t remember everything if you don’t have notes.

By naming our notes file with “aa” at the beginning of the file name, it moves to the top of all the other files except .htaccess in our hosting accounts, making it easy to find, and easy to remember to check BEFORE we go replacing any files during an update.

Saved our bacon to many times to mention.

A typical file might look like this:

I’ve used a wiki for that kind of information too. But the idea of having a file to view works well too.

Thanks for the responses.
I particularly like Kurt’s idea of a text file with notes about the installation.

I suppose it comes down to how much the client is prepared to pay and the level of service they want. I think it would be good to offer an update/review package after 6 months say, to check all is OK.

EDIT
Interesting that after posting this I checked for build updates and there is quite a list of bug fixes, I would have thought that it was quite likely that existing installations would have come across some of these bugs and had a problem. Would this not reflect badly on the developer?