I think the basic premis of his article is sound- Having a schedule for releases lets you better plan the elements of the release (migration? config changes?) a

I think the basic premis of his article is sound- Having a schedule for releases lets you better plan the elements of the release (migration? config changes?) and makes the release an occasion (everybody knows that day is "release day", that afternoon is QA, you can make sure they know what is included in the release). For bugs, I can't agree they should always wait a week. Keeping a production branch where the code is in sync with your deployments lets devs quickly patch and roll out bugfixes, comfortable in the knowledge they aren't deploying somebody else's code at the same time. I've make some customers darn happy by fixing a bug that same afternoon, and I couldn't kick that habit. But for larger feature rollouts or refactorings, I'm a fan of having everybody on the larger team (devs and non-devs) in sync- and that's easiest when there is a regular, predictable schedule. I'd also argue that having a regular schedule for deploys makes you more likely to ship, you need to ship something Thursday! :-)