public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Hammond <[email protected]>
To: Magnus Hagander <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: [email protected]
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?
Date: Wed, 21 Feb 2007 09:56:08 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

On 2/21/07, Magnus Hagander <[email protected]> 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

view thread (32+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  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?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox