Subject: 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: "Andrew Hammond" <[email-masked]>
Date: 20 Feb 2007 17:19:03 -0800

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

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 20 Feb 2007 20:22:30 -0500 (EST)

> I'm willing to write it, if there's a consensus that it would be worth

I think adding to the FAQ is the best solution.  What additional
information to we need there?

-- 
  Bruce Momjian  <[email-masked]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 21 Feb 2007 09:53:43 +0100

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 09:30:47 -0500 (EST)

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

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 21 Feb 2007 15:47:16 +0100

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 10:07:22 -0500 (EST)

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

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 21 Feb 2007 16:42:43 +0100

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

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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 11:08:33 -0500 (EST)

> > upgrading. The community considers <i>not</i> upgrading more risky

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>

---

From: Theo Kramer <[email-masked]>
Date: Wed, 21 Feb 2007 19:52:45 +0200

Could I venture ...

> I changed it to "frequently-encountered bugs".

bugs that may compromise the integrity of your data.

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

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

-- 
Regards
Theo

---

From: "Andrew Hammond" <[email-masked]>
Date: Wed, 21 Feb 2007 09:56:08 -0800

> 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

---

From: bubblboy <[email-masked]>
Date: Wed, 21 Feb 2007 19:43:00 +0100

> remaining exposed to bugs which haven't caused them problems yet.

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

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 21 Feb 2007 19:52:33 +0100

> 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

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 21 Feb 2007 19:54:05 +0100

>     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

---

From: "Andrew Hammond" <[email-masked]>
Date: Wed, 21 Feb 2007 11:13:29 -0800

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 14:46:19 -0500 (EST)

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:
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 14:47:30 -0500 (EST)

> to trigger. (it's also good to mention that we do patch security bugs, I

Yes, text updated for that.

---

From: Bruno Wolff III <[email-masked]>
Date: Wed, 21 Feb 2007 14:01:38 -0600

On Wed, Feb 21, 2007 at 10:07:22 -0500,
> 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.

---

From: "Joshua D. Drake" <[email-masked]>
Date: Wed, 21 Feb 2007 12:06:57 -0800

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

---

From: "Andrew Hammond" <[email-masked]>
Date: Wed, 21 Feb 2007 14:39:20 -0800

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 21 Feb 2007 17:54:23 -0500 (EST)

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>

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 22 Feb 2007 13:35:33 +0100

> to find a better way to communicate about it.

Agreed.

> Releases" to "Actively Maintained Releases")

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

> (perhaps that section of the FAQ) that says something like the

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.

> 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

---

From: "Andrew Hammond" <[email-masked]>
Date: Thu, 22 Feb 2007 15:41:20 -0800

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

> that part. If we do that, I'd definitely like to see a proper page and

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

> policy" or something like that. Like how 8.1 is in principle an "equally

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

Andrew

---

From: "Joshua D. Drake" <[email-masked]>
Date: Thu, 22 Feb 2007 15:44:45 -0800

> 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

--

---

From: "Andrew Hammond" <[email-masked]>
Date: Thu, 22 Feb 2007 15:49:38 -0800

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

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

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 23 Feb 2007 09:33:36 +0100

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 23 Feb 2007 14:07:23 -0500 (EST)

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>

---

From: Dave Page <[email-masked]>
Date: Sun, 25 Feb 2007 05:06:46 +0000

> that part. If we do that, I'd definitely like to see a proper page and

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

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 12 Mar 2007 22:27:39 +0100

> 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

---

From: "Andrew Hammond" <[email-masked]>
Date: Mon, 12 Mar 2007 16:58:34 -0700

> directly from the FAQ. Updates to the text are always welcome ;-)

url please?

Andrew

---

From: Robert Treat <[email-masked]>
Date: Mon, 12 Mar 2007 23:00:08 -0400

> 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

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 13 Mar 2007 10:01:10 +0100

> >directly from the FAQ. Updates to the text are always welcome ;-)

http://www.postgresql.org

//Magnus

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 20 Mar 2007 13:44:09 -0400 (EDT)

> to the website, once the site has updated.

OK, FAQ text removed, and URL added:

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