public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrew Hammond <[email protected]>
To: Magnus Hagander <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: [email protected]
Cc: PostgreSQL www <[email protected]>
Subject: 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?
Date: Thu, 22 Feb 2007 15:41:20 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On 2/22/07, Magnus Hagander <[email protected]> wrote:
> Andrew Hammond wrote:
> > On 2/21/07, Bruce Momjian <[email protected]> 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
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: [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?
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