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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
