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?

From: bubblboy <bubblboy(at)gmail(dot)com>
To: Andrew Hammond <andrew(dot)george(dot)hammond(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-docs(at)postgresql(dot)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?
Date: 2007-02-21 18:43:00
Message-ID: 45DC92B4.9060800@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-www

Andrew Hammond wrote:
> On 2/21/07, Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Magnus Hagander 2007-02-21 18:52:33 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?
Previous Message Andrew Hammond 2007-02-21 17:56:08 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?

Browse pgsql-www by date

  From Date Subject
Next Message Magnus Hagander 2007-02-21 18:52:33 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?
Previous Message Andrew Hammond 2007-02-21 17:56:08 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?