Re: Lifecycle of PostgreSQL releases - Mailing list pgsql-general

Not if you're not affected by the bugs.  Software *always* has bugs.
And new code in your environment is *untested* code in your environment.

If I am not affected by bugs, if I'm under a support contract to correct
any bugs that I *am* affected by (as was the case in Josh's original
argument with RHEL), and no new features are required, then all
upgrading will do is take me from a state of known bugs that don't
affect my systems to unknown bugs or undocumented/unintended changes
that *might* affect my systems.

The PostgreSQL community supports latest release.  Here, "upgrade to
most recent" exactly means "upgrade to the version we know has all the
fixes we've already done".  We ask people to upgrade here so we don't
have to reinvent the wheel just because someone wants to use 7.4.1.
Resources are tight enough just supporting the most recent codebase.
Including every codebase back to the beginning of time would require an
enormous number of people.

Support contracts with, for example, RHEL, don't necessarily work that
way.  They typically say "use our most recent packages; anything else is
not covered and you're on your own".  Because support contracts say
this, they have to maintain the codebase themselves to a fair extent.
Granted, they can just take the changes from -- in this case --
PostgreSQL's source code, but they are the people responsible for the
security of the code base and compatibility of the code base.  That's
*exactly* what you buy when you buy the support contract.

Look at it this way:
The benefits to any upgrade are "bug fix" and "new feature".
The caveats to any upgrade are "new bug" and "feature change".  (PHP and
MySQL are notorious for the latter.)

If "bug fix" is 100% handled by support contract, and "new feature" is
100% not useful, what is my impetus?

For a direct example, why should a business upgrade their desktops from
Windows XP to Windows Vista before 2011 if *none* of the new features
are needed?

--
Brandon Aiken
CS/IT Systems Engineer

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Wednesday, March 21, 2007 9:29 AM
To: Naz Gassiep
Cc: Joshua D. Drake; Erik Jones; CAJ CAJ; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Lifecycle of PostgreSQL releases

Naz Gassiep <naz@mira.net> writes:
> Joshua D. Drake wrote:
>> Example discussion with customer:
> ...
> Finally, in the absence of security concerns or performance issues
(and
> I mean the "we can't afford to buy better hardware" type edge of the
> envelope type issues) there is zero *need* to upgrade.

This line of argument ignores the fact that newer versions often contain
fixes for data-loss-grade bugs.  Now admittedly that is usually an
argument for updating to x.y.z+1 rather than x.y+1, but I think it
destroys any reasoning on the basis of "if it ain't broke".

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@postgresql.org so that your
       message can get through to the mailing list cleanly

** LEGAL DISCLAIMER **
Statements made in this e-mail may or may not reflect the views and
opinions of Wineman Technology, Inc. or its employees.

This e-mail message and any attachments may contain legally privileged,
confidential or proprietary information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are hereby notified
that any dissemination, distribution or copying of this e-mail
message is strictly prohibited. If you have received this message in
error, please immediately notify the sender and delete this e-mail
message from your computer.