Scott Marlowe wrote:
> On Wed, Aug 27, 2008 at 10:58 AM, Andrew Sullivan <ajs@commandprompt.com> wrote:
> > On Tue, Aug 26, 2008 at 08:46:33PM -0400, Lew wrote:
> >> upgrades to PG, it is our duty to inform our bosses of the risk of not
> >> upgrading, so they can properly assess risks and manage them accordingly.
> >
> > I agree. It is, by the same token, your duty to yourself to ensure
> > that, if the answer is, "No," you get that answer in writing so that
> > future failures are not possibly pinned on you as having been
> > negligent in installing stability and security releases.
> >
> > By the way, I always refer to these of late as "security and
> > stability" rather than "minor" releases. I do that because it
> > presents them to the target audience in a way that is understandable.
> > Those releases are, for the project, a maintenance burden and not a
> > way to introduce features. It's wise to keep that in mind when
> > presenting such releases to managers responsible for the decision.
>
> I used to work for an Oracle DBA and while he was quite smart in most
> ways, he really had been trained by Oracle to avoid anything but
> "patches". Upgrades / updates of a db were very scary for him. I had
> to present the minor updates as "patch releases" to get him
> comfortable with them. And have a full implementation plan and all
> that as well.
>
> But if instead he had insisted on running an outdated version of
> PostgreSQL for some goofy reason I would have been looking for another
> job.
The major problem is that much software doesn't have our stability in
minor releases, and hence the perception that many minor release are
risks is accurate, just not in the Postgres case.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +