DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=suahG49r5ahIYGRF2zqpVLVEq2g6zMKEzPK/wAsldt2frXkx4YRNUnXi0/bvfDGxkVPWc7HetBeG2CV3G8pR93djbuKseZ0E1cd/o9aqd4saffvVU4hPmnviBxWoW+ry2QxjyVXdhczuP3I07INmrZK5Sm6+5dFI84vtcFLohh4=
Message-ID: <45DC92B4.9060800@gmail.com>
Date: Wed, 21 Feb 2007 19:43:00 +0100
From: bubblboy <bubblboy@gmail.com>
User-Agent: Thunderbird 2.0b1 (X11/20070117)
MIME-Version: 1.0
To: Andrew Hammond <andrew.george.hammond@gmail.com>
CC: Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
	pgsql-docs@postgresql.org
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?
References: <20070221085343.GB19713@svr2.hagander.net>	
	<200702211430.l1LEUlO00243@momjian.us>	
	<20070221144716.GA21044@svr2.hagander.net>
	<5a0a9d6f0702210956g4dd9cc72gcc363ee7b6aa7615@mail.gmail.com>
In-Reply-To: <5a0a9d6f0702210956g4dd9cc72gcc363ee7b6aa7615@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Hammond wrote:
 > 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

There is one thing I don't understand in this whole discussion; this
upgrading, it is not specific to PostgreSQL, is it? Is there not a page
somewhere on the web that already extensively discusses this issue, no
matter what the program is? "You should always upgrade because blah
blah", I ca not imagine nobody wrote such an article yet. And if not;
write one yourself :) Maybe linking to that article from the postgresql
documentation, if the need is felt...

Just my thoughts on this matter,
b^4