
Providing this information as plain text was doubtless worth the trouble ten years ago, but it seems likely that hardly anyone reads it in this format anymore. And the effort required to maintain these files (in the form of extra-complex markup rules in the relevant parts of the SGML documentation) is significant. So, let's stop doing that and rely solely on the other documentation formats. Per discussion, the plain-text INSTALL instructions might still be worth their keep, so we continue to generate that file. Rather than remove HISTORY and src/test/regress/README from distribution tarballs entirely, replace them with simple stub files that tell the reader where to find the relevant documentation. This is mainly to avoid possibly breaking packaging recipes that expect these files to exist. Back-patch to all supported branches, because simplifying the markup requirements for release notes won't help much unless we do it in all branches.
89 lines
3.1 KiB
Plaintext
89 lines
3.1 KiB
Plaintext
<!-- doc/src/sgml/release.sgml -->
|
|
<!--
|
|
|
|
Typical markup:
|
|
|
|
&<> use & escapes
|
|
PostgreSQL <productname>
|
|
postgresql.conf, pg_hba.conf,
|
|
recovery.conf <filename>
|
|
[A-Z][A-Z_ ]+[A-Z_] <command>, <literal>, <envar>, <acronym>
|
|
[A-Za-z_][A-Za-z0-9_]+() <function>
|
|
-[-A-Za-z_]+ <option>
|
|
[A-Za-z_]/[A-Za-z_]+ <filename>
|
|
psql <application>
|
|
pg_[A-Za-z0-9_]+ <application>, <structname>
|
|
[A-Z][A-Z][A-Z_ ]* <type>
|
|
[a-z]+_[a-z_]+ <varname>
|
|
|
|
non-ASCII characters find using grep -P '[\x80-\xFF]'
|
|
convert to HTML4 named entity (&) escapes
|
|
|
|
official: http://www.w3.org/TR/html4/sgml/entities.html
|
|
one page: http://www.zipcon.net/~swhite/docs/computers/browsers/entities_page.html
|
|
other lists: http://www.zipcon.net/~swhite/docs/computers/browsers/entities.html
|
|
http://www.zipcon.net/~swhite/docs/computers/browsers/entities_page.html
|
|
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
|
|
|
|
we cannot use UTF8 because SGML Docbook does not support it
|
|
|
|
do not use numeric _UTF_ numeric character escapes (&#nnn;),
|
|
we can only use Latin1
|
|
|
|
Example: Alvaro Herrera is Álvaro Herrera
|
|
|
|
wrap long lines
|
|
|
|
For new features, add links to the documentation sections.
|
|
|
|
-->
|
|
|
|
<appendix id="release">
|
|
<title>Release Notes</title>
|
|
|
|
<para>
|
|
The release notes contain the significant changes in each
|
|
<productname>PostgreSQL</> release, with major features and migration
|
|
issues listed at the top. The release notes do not contain changes
|
|
that affect only a few users or changes that are internal and therefore not
|
|
user-visible. For example, the optimizer is improved in almost every
|
|
release, but the improvements are usually observed by users as simply
|
|
faster queries.
|
|
</para>
|
|
|
|
<para>
|
|
A complete list of changes for each release can be obtained by
|
|
viewing the <link linkend="git">Git</link> logs for each release.
|
|
The <ulink
|
|
url="http://archives.postgresql.org/pgsql-committers/"><literal>pgsql-committers</literal>
|
|
email list</ulink> records all source code changes as well. There is also
|
|
a <ulink url="http://git.postgresql.org/gitweb?p=postgresql.git;a=summary">web
|
|
interface</ulink> that shows changes to specific files.
|
|
</para>
|
|
|
|
<para>
|
|
The name appearing next to each item represents the major developer for
|
|
that item. Of course all changes involve community discussion and patch
|
|
review, so each item is truly a community effort.
|
|
</para>
|
|
|
|
<!--
|
|
To add a new major-release series, add an entry here and in filelist.sgml.
|
|
|
|
The reason for splitting the release notes this way is so that appropriate
|
|
subsets can easily be copied into back branches.
|
|
-->
|
|
&release-9.3;
|
|
&release-9.2;
|
|
&release-9.1;
|
|
&release-9.0;
|
|
&release-8.4;
|
|
&release-8.3;
|
|
&release-8.2;
|
|
&release-8.1;
|
|
&release-8.0;
|
|
&release-7.4;
|
|
&release-old;
|
|
|
|
</appendix>
|