DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=YftGWz/t4TWDCbMRX5oTnBsH8Q6q4oaeN2P7jGhHwjs6a9CWlh/rlrYtCnPonwvujuV3ZdLxDUNMTcuX+JSam0LrNJkGzC9BPYiqPUHEn/xHp/PdSmhgLiRrFtMJlBkiF4++TFSX1QCHqW48+mj5cRLmAmfuQxU5Ehxx0+xAFxw=
Message-ID: <5a0a9d6f0702210956g4dd9cc72gcc363ee7b6aa7615@mail.gmail.com>
Date: Wed, 21 Feb 2007 09:56:08 -0800
From: "Andrew Hammond" <andrew.george.hammond@gmail.com>
To: "Magnus Hagander" <magnus@hagander.net>
Subject: Re: should we have a separate page that clearly defines what a minor
	release is and why it's a good idea to keep up with them?
Cc: "Bruce Momjian" <bruce@momjian.us>, pgsql-docs@postgresql.org
In-Reply-To: <20070221144716.GA21044@svr2.hagander.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070221085343.GB19713@svr2.hagander.net>
	<200702211430.l1LEUlO00243@momjian.us>
	<20070221144716.GA21044@svr2.hagander.net>

On 2/21/07, Magnus Hagander <magnus@hagander.net> wrote:
> > > > I think adding to the FAQ is the best solution.  What additional
> > > > information to we need there?
> > >
> > > I think it's important enough (and unclear enough to a lot of people)
> > > that it shuold have it's own non-FAQ section. Either as a page on the
> > > website or as a page in the documentation.
> >
> > If you look at the developer documentation, you will see I overhauled
> > the instructions for upgrading a minor release:
> >
> >       http://momjian.us/main/writings/pgsql/sgml/install-upgrading.html
> >
> > I think that would be a good place to add more text.  What additional
> > text do we need?  Something about how you are less likely to hit a new
> > bug if you minor upgrade than if you stay on an older release?
>
> Something about how we put only critical fixes in back branches, and not
> new features. How we *really* recommend that people should always be on
> the latest release in a branch. How we will never (knowingly) change the
> behaviour of anything in a back branch (without being *very* clear in
> the release notes of what and why). More focus on how easy that part is.
>
> Mainly, I think people don't upgrade because (a) they don't know what
> they gain, and (b) they're scared something will break. We need to
> counter those two arguments.

I think this exactly defines what I'm looking for. The most basic
approach to risk management is "if it works, don't change it". What
I'm looking for is something with which to convince people that the
risk of breakage is so low that it's outweighed by the risk of
remaining exposed to bugs which haven't caused them problems yet.

Andrew