Re: [DOCS] 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?

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.

Andrew

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?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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.

//Magnus

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?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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.

//Magnus

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> OK, the FAQ now has:
>
> <P>The PostgreSQL team makes only bug fixes in minor releases,

I don't think there is a causality between the above and the below.

> 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 is a "common bug"?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > OK, the FAQ now has:
> >
> > <P>The PostgreSQL team makes only bug fixes in minor releases,
>
> I don't think there is a causality between the above and the below.
>
> > 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 is a "common bug"?

I changed it to "frequently-encountered bugs".

New text:

<P>The PostgreSQL team adds only bug fixes to minor releases. 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 frequently-encountered bugs to reduce the risk of
upgrading. The community considers <i>not</i> upgrading more risky
that upgrading.</P>

<P>Upgrading to a minor release, e.g. 8.1.5 to 8.1.6, does not does
not require a dump and restore; merely stop the database server,
install the updated binaries, and restart the server.</P>

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Could I venture ...

On Wed, 2007-02-21 at 11:08 -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > OK, the FAQ now has:
> > >
> > > <P>The PostgreSQL team makes only bug fixes in minor releases,
> >
> > I don't think there is a causality between the above and the below.
> >
> > > 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 is a "common bug"?
>
> I changed it to "frequently-encountered bugs".

bugs that may compromise the integrity of your data.

>
> New text:
>
> <P>The PostgreSQL team adds only bug fixes to minor releases. All

<P>The PostgreSQL team only adds bug fixes to minor releases. 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 frequently-encountered bugs to reduce the risk of
> upgrading. The community considers <i>not</i> upgrading more risky
> that upgrading.</P>
>
> <P>Upgrading to a minor release, e.g. 8.1.5 to 8.1.6, does not does
> not require a dump and restore; merely stop the database server,
> install the updated binaries, and restart the server.</P>
>
--
Regards
Theo

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

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

On Wed, Feb 21, 2007 at 07:43:00PM +0100, bubblboy wrote:
> 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...

What we want to push is that we don't add stuff in stable branches.
Unlike Certain Other Databases that we are often compared to...

//Magnus

On Wed, Feb 21, 2007 at 11:08:33AM -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > OK, the FAQ now has:
> > >
> > > <P>The PostgreSQL team makes only bug fixes in minor releases,
> >
> > I don't think there is a causality between the above and the below.
> >
> > > 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 is a "common bug"?
>
> I changed it to "frequently-encountered bugs".
>
> New text:
>
> <P>The PostgreSQL team adds only bug fixes to minor releases. 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 frequently-encountered bugs to reduce the risk of
> upgrading. The community considers <i>not</i> upgrading more risky
> that upgrading.</P>
>
> <P>Upgrading to a minor release, e.g. 8.1.5 to 8.1.6, does not does
> not require a dump and restore; merely stop the database server,
> install the updated binaries, and restart the server.</P>

I still think this should live somewhere other than the FAQ. (It can
live in the FAQ as well, of course, but..)

I'm not entirely sure about the "frequently-encountered". AFAIK, we fix
serious stability bugs (or security bugs) even if they are fairly hard
to trigger. (it's also good to mention that we do patch security bugs, I
think)

//Magnus

On 2/21/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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?

That it's in the FAQ? I think this is one of the most common
misunderstandings for people outside the community, so I think we need
to find a better way to communicate about it.

On the front page, we already have "Latest Releases" with links to the
most recent release for each version still actively maintained and
release notes. (Would it make sense to change that title from "Latest
Releases" to "Actively Maintained Releases")

What I'd like to see right under it is something like "Minimize your
risk by keeping up with minor revisions." Which would link to a page
(perhaps that section of the FAQ) that says something like the
following.

- "The PostgreSQL community provides minor releases on an as-needed
basis to address bugs. While all upgrades involve change which carries
risk, minor releases have the minimum amount of change necessary to
address bugs that are serious but generally obscure (here we could
link to an actual description of what does or does not go into a minor
release, if we have such a thing). The community considers the risk of
minor version upgrades to be less than the risk of remaining exposed
to these bugs. When planning your maintenance strategy, please be sure
to keep abreast of minor releases.

There was a posting a while ago about projected lifespans of major
releases that got side-tracked into a discussion about dropping
windows builds for 8.0 and 8.1. I think this is related, but I haven't
figured out how we can express these ideas.

Andrew

Updated text:

<P>The PostgreSQL team only adds bug fixes to minor releases. 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 frequently-encountered, security, and data corruption
bugs, to reduce the risk of upgrading. The community considers
<i>not</i> upgrading more risky than upgrading.</P>

---------------------------------------------------------------------------

Theo Kramer wrote:
> Could I venture ...
>
> On Wed, 2007-02-21 at 11:08 -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > OK, the FAQ now has:
> > > >
> > > > <P>The PostgreSQL team makes only bug fixes in minor releases,
> > >
> > > I don't think there is a causality between the above and the below.
> > >
> > > > 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 is a "common bug"?
> >
> > I changed it to "frequently-encountered bugs".
>
> bugs that may compromise the integrity of your data.
>
> >
> > New text:
> >
> > <P>The PostgreSQL team adds only bug fixes to minor releases. All
>
> <P>The PostgreSQL team only adds bug fixes to minor releases. 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 frequently-encountered bugs to reduce the risk of
> > upgrading. The community considers <i>not</i> upgrading more risky
> > that upgrading.</P>
> >
> > <P>Upgrading to a minor release, e.g. 8.1.5 to 8.1.6, does not does
> > not require a dump and restore; merely stop the database server,
> > install the updated binaries, and restart the server.</P>
> >
> --
> Regards
> Theo
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Magnus Hagander wrote:
> I'm not entirely sure about the "frequently-encountered". AFAIK, we fix
> serious stability bugs (or security bugs) even if they are fairly hard
> to trigger. (it's also good to mention that we do patch security bugs, I
> think)

Yes, text updated for that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Wed, Feb 21, 2007 at 10:07:22 -0500,
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> <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?

The "soon as available" seems to be too aggressive to me. This seems to
suggest (to me at least) that these upgrades are so important that you
might want to skimp on QA to get them in place rapidly. While that may
sometimes be true, I don't think it is always the case for everybody.

Bruno Wolff III wrote:
> On Wed, Feb 21, 2007 at 10:07:22 -0500,
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> <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?
>
> The "soon as available" seems to be too aggressive to me. This seems to
> suggest (to me at least) that these upgrades are so important that you
> might want to skimp on QA to get them in place rapidly. While that may
> sometimes be true, I don't think it is always the case for everybody.

Hmmm how about:

All users should upgrade to the most recent minor release as soon
as is reasonable for the environment. While upgrades always have some
risk, PostgreSQL minor releases fix only bugs to reduce the risk of
upgrading. To reduce issues a user may encounter the community strongly
suggests reviewing of the release notes for their particular version.

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On 2/21/07, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> All users should upgrade to the most recent minor release as soon
> as is reasonable for the environment. While upgrades always have some
> risk, PostgreSQL minor releases fix only bugs to reduce the risk of
> upgrading. To reduce issues a user may encounter the community strongly

Or...

Minor releases are intended to minimize the risk associated with
change while addressing important stability or security bugs. All
users are strongly encouraged to keep abreast of minor releases as
their maintenance windows permit. ...

Andrew

Updated wording:

<P>The PostgreSQL team only adds bug fixes to minor releases. All
users should upgrade to the most recent minor release as soon as
possible. While upgrades always have some risk, PostgreSQL minor
releases fix only frequently-encountered, security, and data corruption
bugs, to reduce the risk of upgrading. The community considers
<i>not</i> upgrading more risky than upgrading.</P>

---------------------------------------------------------------------------

Joshua D. Drake wrote:
> Bruno Wolff III wrote:
> > On Wed, Feb 21, 2007 at 10:07:22 -0500,
> > Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> <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?
> >
> > The "soon as available" seems to be too aggressive to me. This seems to
> > suggest (to me at least) that these upgrades are so important that you
> > might want to skimp on QA to get them in place rapidly. While that may
> > sometimes be true, I don't think it is always the case for everybody.
>
> Hmmm how about:
>
>
> All users should upgrade to the most recent minor release as soon
> as is reasonable for the environment. While upgrades always have some
> risk, PostgreSQL minor releases fix only bugs to reduce the risk of
> upgrading. To reduce issues a user may encounter the community strongly
> suggests reviewing of the release notes for their particular version.
>
>
> --
>
> === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> Providing the most comprehensive PostgreSQL solutions since 1997
> http://www.commandprompt.com/
>
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> PostgreSQL Replication: http://www.commandprompt.com/products/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Andrew Hammond wrote:
> On 2/21/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
>> 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?
>
> That it's in the FAQ? I think this is one of the most common
> misunderstandings for people outside the community, so I think we need
> to find a better way to communicate about it.

Agreed.

> On the front page, we already have "Latest Releases" with links to the
> most recent release for each version still actively maintained and
> release notes. (Would it make sense to change that title from "Latest
> Releases" to "Actively Maintained Releases")

I think not. The meaning is "latest releases available for each branch",
not "these are the actively maintained branches".

> What I'd like to see right under it is something like "Minimize your
> risk by keeping up with minor revisions." Which would link to a page
> (perhaps that section of the FAQ) that says something like the
> following.

I'm bouncing this over to -www as well to hear what people think about
that part. If we do that, I'd definitely like to see a proper page and
not just a FAQ link.

> There was a posting a while ago about projected lifespans of major
> releases that got side-tracked into a discussion about dropping
> windows builds for 8.0 and 8.1. I think this is related, but I haven't
> figured out how we can express these ideas.

I fully agree that we need some kind of page that explains "versioning
policy" or something like that. Like how 8.1 is in principle an "equally
major" release as 8.0.

//Magnus

On 2/22/07, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Andrew Hammond wrote:
> > On 2/21/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> >> 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?
> >
> > That it's in the FAQ? I think this is one of the most common
> > misunderstandings for people outside the community, so I think we need
> > to find a better way to communicate about it.
>
> Agreed.
>
>
> > On the front page, we already have "Latest Releases" with links to the
> > most recent release for each version still actively maintained and
> > release notes. (Would it make sense to change that title from "Latest
> > Releases" to "Actively Maintained Releases")
>
> I think not. The meaning is "latest releases available for each branch",
> not "these are the actively maintained branches".

Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then?

Clearly there is some criteria for which branches are presented there.

> > What I'd like to see right under it is something like "Minimize your
> > risk by keeping up with minor revisions." Which would link to a page
> > (perhaps that section of the FAQ) that says something like the
> > following.
>
> I'm bouncing this over to -www as well to hear what people think about
> that part. If we do that, I'd definitely like to see a proper page and
> not just a FAQ link.

I agree, however, it could start as a FAQ link and go from there as
time permits.

> > There was a posting a while ago about projected lifespans of major
> > releases that got side-tracked into a discussion about dropping
> > windows builds for 8.0 and 8.1. I think this is related, but I haven't
> > figured out how we can express these ideas.
>
> I fully agree that we need some kind of page that explains "versioning
> policy" or something like that. Like how 8.1 is in principle an "equally
> major" release as 8.0.

I am willing to take a shot at writing a first draft of this page if
there's interest in having it.

Andrew

>> > On the front page, we already have "Latest Releases" with links to the
>> > most recent release for each version still actively maintained and
>> > release notes. (Would it make sense to change that title from "Latest
>> > Releases" to "Actively Maintained Releases")
>>
>> I think not. The meaning is "latest releases available for each branch",
>> not "these are the actively maintained branches".
>
> Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then?
>
> Clearly there is some criteria for which branches are presented there.

<7.3 is EOL. We still back patch what we can but they are considered
deprecated.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On 2/22/07, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

> >> > On the front page, we already have "Latest Releases" with links to the
> >> > most recent release for each version still actively maintained and
> >> > release notes. (Would it make sense to change that title from "Latest
> >> > Releases" to "Actively Maintained Releases")
> >>
> >> I think not. The meaning is "latest releases available for each branch",
> >> not "these are the actively maintained branches".
> >
> > Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then?
> >
> > Clearly there is some criteria for which branches are presented there.
>
> <7.3 is EOL. We still back patch what we can but they are considered
> deprecated.

Yeah, I figured that was the criteria. So, is it not reasonable to say
that the releases listed on the front page under "Latest Releases" are
actually "Current minor release for branches which have not reached
EoL"? Perhaps instead of "Latest Releases" or "Actively Maintained
Releases" something like "Current Releases" says that better?

Andrew

Andrew Hammond wrote:
> On 2/22/07, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
>> >> > On the front page, we already have "Latest Releases" with links
>> to the
>> >> > most recent release for each version still actively maintained and
>> >> > release notes. (Would it make sense to change that title from
>> "Latest
>> >> > Releases" to "Actively Maintained Releases")
>> >>
>> >> I think not. The meaning is "latest releases available for each
>> branch",
>> >> not "these are the actively maintained branches".
>> >
>> > Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then?
>> >
>> > Clearly there is some criteria for which branches are presented there.
>>
>> <7.3 is EOL. We still back patch what we can but they are considered
>> deprecated.
>
> Yeah, I figured that was the criteria. So, is it not reasonable to say
> that the releases listed on the front page under "Latest Releases" are
> actually "Current minor release for branches which have not reached
> EoL"? Perhaps instead of "Latest Releases" or "Actively Maintained
> Releases" something like "Current Releases" says that better?

"Current Releases" I'm fine with - that seems to get the point across a
bit better than what we have today, I think.

If people agree, we'll just go bug Tom (or was it Toms wife?) about
generating a new image for us to put there.

//Magnus

I have again updated the FAQ to mention the major/minor release
numbering:

<H3 id="item3.6">3.6) What is the upgrade process for PostgreSQL?</H3>

<P>PostgreSQL major releases include new features and occur roughly
once every year. A major release is numbered by increasing either
the first or second part of the version number, e.g. 8.1 to 8.2.

<P>Major releases usually change the internal format of system tables
and data files. These changes are often complex, so we don't maintain
backward compatibility for data files. A dump/reload of the database
is required for major upgrades.</P>

<P>Minor releases are numbered by increasing the third part of the
version number, e.g. 8.1.5 to 8.1.6. The PostgreSQL team only adds
bug fixes to minor releases. All users should upgrade to the most
recent minor release as soon as possible. While upgrades always have
some risk, PostgreSQL minor releases fix only frequently-encountered,
security, and data corruption bugs to reduce the risk of upgrading.
The community considers <i>not</i> upgrading riskier than
upgrading.</P>
`
<P>Upgrading to a minor release does not does not require a dump and
restore; merely stop the database server, install the updated binaries,
and restart the server.</P>

---------------------------------------------------------------------------

Bruno Wolff III wrote:
> On Wed, Feb 21, 2007 at 10:07:22 -0500,
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > <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?
>
> The "soon as available" seems to be too aggressive to me. This seems to
> suggest (to me at least) that these upgrades are so important that you
> might want to skimp on QA to get them in place rapidly. While that may
> sometimes be true, I don't think it is always the case for everybody.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Magnus Hagander wrote:
> I'm bouncing this over to -www as well to hear what people think about
> that part. If we do that, I'd definitely like to see a proper page and
> not just a FAQ link.

Agreed, though there's no reason not to have both. Including it on the
main site will add an air of legitimacy to satisfy PHBs.

Regards Dave

Dave Page wrote:
> Magnus Hagander wrote:
>> I'm bouncing this over to -www as well to hear what people think about
>> that part. If we do that, I'd definitely like to see a proper page and
>> not just a FAQ link.
>
> Agreed, though there's no reason not to have both. Including it on the
> main site will add an air of legitimacy to satisfy PHBs.

I've added such a page to the site now, and linked it in from the
support section and from the front page. The text is more or less copied
directly from the FAQ. Updates to the text are always welcome ;-)

I suggest that we remove it from the FAQ, or replace it with a reference
to the website, once the site has updated.

//Magnus

On 3/12/07, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Dave Page wrote:
> > Magnus Hagander wrote:
> >> I'm bouncing this over to -www as well to hear what people think about
> >> that part. If we do that, I'd definitely like to see a proper page and
> >> not just a FAQ link.
> >
> > Agreed, though there's no reason not to have both. Including it on the
> > main site will add an air of legitimacy to satisfy PHBs.
>
> I've added such a page to the site now, and linked it in from the
> support section and from the front page. The text is more or less copied
> directly from the FAQ. Updates to the text are always welcome ;-)

url please?

Andrew

On Monday 12 March 2007 17:27, Magnus Hagander wrote:
> Dave Page wrote:
> > Magnus Hagander wrote:
> >> I'm bouncing this over to -www as well to hear what people think about
> >> that part. If we do that, I'd definitely like to see a proper page and
> >> not just a FAQ link.
> >
> > Agreed, though there's no reason not to have both. Including it on the
> > main site will add an air of legitimacy to satisfy PHBs.
>
> I've added such a page to the site now, and linked it in from the
> support section and from the front page. The text is more or less copied
> directly from the FAQ. Updates to the text are always welcome ;-)
>
> I suggest that we remove it from the FAQ, or replace it with a reference
> to the website, once the site has updated.
>

I'd suggest we add this into the documentation where it belongs :-)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

On Mon, Mar 12, 2007 at 04:58:34PM -0700, Andrew Hammond wrote:
> On 3/12/07, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> >Dave Page wrote:
> >> Magnus Hagander wrote:
> >>> I'm bouncing this over to -www as well to hear what people think about
> >>> that part. If we do that, I'd definitely like to see a proper page and
> >>> not just a FAQ link.
> >>
> >> Agreed, though there's no reason not to have both. Including it on the
> >> main site will add an air of legitimacy to satisfy PHBs.
> >
> >I've added such a page to the site now, and linked it in from the
> >support section and from the front page. The text is more or less copied
> >directly from the FAQ. Updates to the text are always welcome ;-)
>
> url please?

http://www.postgresql.org

//Magnus

Magnus Hagander wrote:
> Dave Page wrote:
> > Magnus Hagander wrote:
> >> I'm bouncing this over to -www as well to hear what people think about
> >> that part. If we do that, I'd definitely like to see a proper page and
> >> not just a FAQ link.
> >
> > Agreed, though there's no reason not to have both. Including it on the
> > main site will add an air of legitimacy to satisfy PHBs.
>
> I've added such a page to the site now, and linked it in from the
> support section and from the front page. The text is more or less copied
> directly from the FAQ. Updates to the text are always welcome ;-)
>
> I suggest that we remove it from the FAQ, or replace it with a reference
> to the website, once the site has updated.

OK, FAQ text removed, and URL added:

http://www.postgresql.org/support/versioning

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +