public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Magnus Hagander <[email protected]>
Cc: Andrew Hammond <[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 10:07:22 -0500 (EST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
Magnus Hagander wrote:
> On Wed, Feb 21, 2007 at 09:30:47AM -0500, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > On Tue, Feb 20, 2007 at 08:22:30PM -0500, Bruce Momjian wrote:
> > > > Andrew Hammond wrote:
> > > > > I know it's mentioned in the FAQ, but I'd like to have a separate page
> > > > > that describes what a minor release is, and why it's a good idea to
> > > > > keep up with them. Basically, I want something simple and clear to
> > > > > point middle-managers at when they ask me why I want to upgrade the
> > > > > database.
> > > > >
> > > > > I'm willing to write it, if there's a consensus that it would be worth
> > > > > having.
> > > >
> > > > 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.
OK, the FAQ now has:
<P>The PostgreSQL team makes only bug fixes in minor releases,
so, for example, upgrading from 7.4.8 to 7.4.9 does not require
a dump and restore; merely stop the database server, install
the updated binaries, and restart the server.</P>
<P>All users should upgrade to the most recent minor release as soon
as it is available. While upgrades always have some risk, PostgreSQL
minor releases fix only common bugs to reduce the risk of upgrading.
The community considers <i>not</i> upgrading more risky that
upgrading.</P>
What should change about this text?
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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