<!-- doc/src/sgml/release.sgml -->
<!--

Typical markup:

&<>                             use & escapes
PostgreSQL                      <productname>
postgresql.conf, pg_hba.conf    <filename>
[A-Z][A-Z ]+[A-Z]               <command>, <literal>, <envar>
[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>, <varname>

non-ASCII characters            convert to HTML4 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
          http://www.pemberley.com/janeinfo/latin1.html#latexta

wrap long lines

For new features, add links to the documentation sections.  Use </link>
not just </> so that generate_history.pl can remove it, so HISTORY.html
can be created without links to the main documentation.  Don't use <xref>.

-->

<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="cvs">CVS</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://anoncvs.postgresql.org/cvsweb.cgi/pgsql/">web
   interface</ulink> that shows changes to specific files.
   <!-- we need a file containing the CVS logs for each release, and something
   like the SVN web interface that groups commits but has branches -->
  </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.
  Follow the naming convention, or you'll confuse generate_history.pl.

  The reason for splitting the release notes this way is so that appropriate
  subsets can easily be copied into back branches.
-->
&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>
