On Fri, 10 Oct 2008, Jens Hoffrichter wrote: > Generally speaking, it is of course better to keep at an actual release, > but as so often, the need of having an uninterrupted system with as few > downtimes as possible, is very big. And as an upgrade isn't done lightly > (no matter how good the upgrade path of the software in question is), it > is normally only done if there are real issues pressing an upgrade, or a > general systems upgrade. But the latter one is seldomly done, the > software remains old, if not ancient ;)
The longer you leave upgrading, the more difficult it becomes (Exim isn't particularly prone to this however, rarely is an Exim upgrade not trivial and backwardly compatible). The more time you leave between upgrades, the more customers expect "perfect" service, and the more agitated they get when it has to go down for some (presumably now essential) reason. Agreeing regular maintenance windows with your customers (which do not need to be used if there is no particular issue) as part of the SLA helps to alleviate these issues. Having a "very big need" to have "as few downtimes as possible" is a bad situation to be backed in to. Mail services, in particular, are quite easy to set up in a redundant way where service can be split across devices allowing maintenance of each without disruption to the service as a whole. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services University Of Strathclyde, Glasgow, UK -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
