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?
От | bubblboy |
---|---|
Тема | 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? |
Дата | |
Msg-id | 45DC92B4.9060800@gmail.com обсуждение исходный текст |
Ответ на | 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? ("Andrew Hammond" <andrew.george.hammond@gmail.com>) |
Ответы |
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?
|
Список | pgsql-docs |
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
В списке pgsql-docs по дате отправления: