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.