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@momjian.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@momjian.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@momjian.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@momjian.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@hagander.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@hagander.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@momjian.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?
--
Bruce Momjian <bruce@momjian.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@momjian.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@momjian.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@momjian.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@commandprompt.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@momjian.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?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
