Version information in docs

Started by Jim Nasbyabout 21 years ago7 messagesdocs
Jump to latest
#1Jim Nasby
Jim.Nasby@BlueTreble.com

ISTM it would be very useful if the docs specified what version a
feature that would break in older versions was implemented in. The
example that comes to mind is argument names in CREATE FUNCTION, which
was added in 8.0. The 8.0 docs (http://lnk.nu/postgresql.org/1y3.html)
mention the ability to name arguments, but it doesn't mention that the
feature was added in 8.0 and can not be used in prior versions. Anyone
who's trying to write code that will run on multiple versions of
PostgreSQL would want to know this.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Nasby (#1)
Re: Version information in docs

"Jim C. Nasby" <decibel@decibel.org> writes:

ISTM it would be very useful if the docs specified what version a
feature that would break in older versions was implemented in. The
example that comes to mind is argument names in CREATE FUNCTION, which
was added in 8.0. The 8.0 docs (http://lnk.nu/postgresql.org/1y3.html)
mention the ability to name arguments, but it doesn't mention that the
feature was added in 8.0 and can not be used in prior versions. Anyone
who's trying to write code that will run on multiple versions of
PostgreSQL would want to know this.

The release notes cover that; or you can compare the docs for the oldest
and newest versions you want to work with. I think it would be more
confusing than helpful for the reference pages to try to cover all the
changes from version to version.

regards, tom lane

#3Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Tom Lane (#2)
Re: Version information in docs

On Sun, Mar 27, 2005 at 08:54:22PM -0500, Tom Lane wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

ISTM it would be very useful if the docs specified what version a
feature that would break in older versions was implemented in. The
example that comes to mind is argument names in CREATE FUNCTION, which
was added in 8.0. The 8.0 docs (http://lnk.nu/postgresql.org/1y3.html)
mention the ability to name arguments, but it doesn't mention that the
feature was added in 8.0 and can not be used in prior versions. Anyone
who's trying to write code that will run on multiple versions of
PostgreSQL would want to know this.

The release notes cover that; or you can compare the docs for the oldest
and newest versions you want to work with. I think it would be more
confusing than helpful for the reference pages to try to cover all the
changes from version to version.

Well, it might not need to cover all changes, just ones that might be
easy to overlook. Besides, are there really that many syntax changes
from one version to another?

Another idea I had is that if there was actual metadata in the document
source about the version info, it would be possible to output different
amounts or kinds of information depending on how old the change was. For
example, I doubt anyone would possibly care about changes prior to 7.0
at this point, and most people probably wouldn't care about changes
prior to 7.3 or even 7.4, so the default documentation wouldn't need to
show that info. Another alternative is providing a history link on
features that takes you to appropriate documentation about what changes
have occured and when. In this case, it would just mention that argument
names first appeared in 8.0.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

#4Thomas F.O'Connell
tfo@sitening.com
In reply to: Tom Lane (#2)
Re: Version information in docs

For comparison, the MySQL docs seem to stay monolithic, at least
online. As in, they don't provide a different version of the manual for
3.23, 4.0, 4.1, 5.0, etc.

They have a single manual that seems to be pretty thorough about the
version in which various features came online.

I haven't concluded which style of documentation is more intuitive, but
when I've had to use MySQL, it has been nice to be able to go to one
document and look to see whether something has been implemented and
also when it was implemented. I suppose the same thing could be
achieved if the manual itself were versioned rather than individual
features being versioned, but you do have to look through various
versions of the manual if you're tracking features in PostgreSQL. If
you were dealing with multiple versions, it could become tedious. I've
dealt with many different versions of MySQL, and it is definitely handy
to have a history in single pages for features. Granted, the feature
set and SQL compatibility for MySQL have been much more volatile than
for PostgreSQL in the past few years, so maybe it's more striking and
necessary for them.

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source — Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Mar 27, 2005, at 7:54 PM, Tom Lane wrote:

Show quoted text

"Jim C. Nasby" <decibel@decibel.org> writes:

ISTM it would be very useful if the docs specified what version a
feature that would break in older versions was implemented in. The
example that comes to mind is argument names in CREATE FUNCTION, which
was added in 8.0. The 8.0 docs (http://lnk.nu/postgresql.org/1y3.html)
mention the ability to name arguments, but it doesn't mention that the
feature was added in 8.0 and can not be used in prior versions. Anyone
who's trying to write code that will run on multiple versions of
PostgreSQL would want to know this.

The release notes cover that; or you can compare the docs for the
oldest
and newest versions you want to work with. I think it would be more
confusing than helpful for the reference pages to try to cover all the
changes from version to version.

regards, tom lane

#5Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Thomas F.O'Connell (#4)
Re: Version information in docs

Something else that comes to mind... going back to older versions of the
manual wouldn't be nearly as tedeous if there were links to older
versions somewhere on the pages. Maybe at every section header?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

#6Bruce Momjian
bruce@momjian.us
In reply to: Jim Nasby (#5)
Re: Version information in docs

Jim C. Nasby wrote:

Something else that comes to mind... going back to older versions of the
manual wouldn't be nearly as tedeous if there were links to older
versions somewhere on the pages. Maybe at every section header?

The good thing about our current setup is that all changes are
centralized in the release notes.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#7Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Bruce Momjian (#6)
Re: Version information in docs

On Mon, Mar 28, 2005 at 05:52:30PM -0500, Bruce Momjian wrote:

Jim C. Nasby wrote:

Something else that comes to mind... going back to older versions of the
manual wouldn't be nearly as tedeous if there were links to older
versions somewhere on the pages. Maybe at every section header?

The good thing about our current setup is that all changes are
centralized in the release notes.

I don't see how my suggestion would necessarily change that. But if
you're trying to figure out when a feature was introduced sifting
through a bunch of release notes seems as bad as sifting through old
versions of the manuals. Or maybe even worse; at least with the manuals
you know what section to look in.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"