Subject: Version information in docs

From: "Jim C. Nasby" <[email-masked]>
Date: Sun, 27 Mar 2005 15:20:50 -0600

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               [email-masked] 
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?"

---

From: Tom Lane <[email-masked]>
Date: Sun, 27 Mar 2005 20:54:22 -0500

> 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

---

From: "Jim C. Nasby" <[email-masked]>
Date: Sun, 27 Mar 2005 20:19:46 -0600

> 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               [email-masked] 
Give your computer some brain candy! www.distributed.net Team #1828

---

From: Thomas F.O'Connell <[email-masked]>
Date: Mon, 28 Mar 2005 10:03:49 -0600

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

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 28 Mar 2005 14:54:23 -0600

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               [email-masked] 
Give your computer some brain candy! www.distributed.net Team #1828

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 28 Mar 2005 17:52:30 -0500 (EST)

> 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
  [email-masked]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---

From: "Jim C. Nasby" <[email-masked]>
Date: Tue, 29 Mar 2005 13:17:47 -0600

> 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               [email-masked] 
Give your computer some brain candy! www.distributed.net Team #1828