doc/src/sgml/release.sgml

   1 <!-- $PostgreSQL$ -->
   2 <!--
   3
   4 Typical markup:
   5
   6 &<>                             use & escapes
   7 PostgreSQL                      <productname>
   8 postgresql.conf, pg_hba.conf    <filename>
   9 [A-Z][A-Z ]+[A-Z]               <command>
  10 [A-Za-z_][A-Za-z0-9_]+()        <function>
  11 [A-Za-z_]/[A-Za-z_]+            <filename>
  12 pg_[A-Za-z0-9_]                 <application>
  13 [A-Z][A-Z][A-Z_ ]*              <type>, <envar>, <literal>
  14
  15 non-ASCII characters            convert to HTML4 entity (&) escapes
  16
  17         official:      http://www.w3.org/TR/html4/sgml/entities.html
  18         one page:      http://www.zipcon.net/~swhite/docs/computers/browsers/entities_page.html
  19         other lists:   http://www.zipcon.net/~swhite/docs/computers/browsers/entities.html
  20                        http://www.zipcon.net/~swhite/docs/computers/browsers/entities_page.html
  21                        http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
  22
  23         we cannot use UTF8 because SGML Docbook
  24         does not support it
  25           http://www.pemberley.com/janeinfo/latin1.html#latexta
  26
  27 wrap long lines
  28
  29 For new features, add links to the documentation sections.  Use </link>
  30 not just </> so that generate_history.pl can remove it, so HISTORY.html
  31 can be created without links to the main documentation.
  32
  33 -->
  34
  35 <appendix id="release">
  36  <title>Release Notes</title>
  37
  38   <para>
  39    The release notes contain the significant changes in each
  40    <productname>PostgreSQL</> release, with major features and migration
  41    issues listed at the top.  The release notes do not contain changes
  42    that affect only a few users or changes that are internal and therefore not
  43    user-visible.  For example, the optimizer is improved in almost every
  44    release, but the improvements are usually observed by users as simply
  45    faster queries.
  46   </para>
  47
  48   <para>
  49    A complete list of changes for each release can be obtained by
  50    viewing the <link linkend="cvs">CVS</link> logs for each release.
  51    The <ulink
  52    url="http://archives.postgresql.org/pgsql-committers/">pgsql-committers
  53    email list</ulink> records all source code changes as well.  There is also
  54    a <ulink url="http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/">web
  55    interface</ulink> that shows changes to specific files.
  56    <!-- we need a file containing the CVS logs for each release, and something
  57    like the SVN web interface that groups commits but has branches -->
  58   </para>
  59
  60   <para>
  61    The name appearing next to each item represents the major developer for
  62    that item.  Of course all changes involve community discussion and patch
  63    review, so each item is truly a community effort.
  64   </para>
  65
  66 <!--
  67   To add a new major-release series, add an entry here and in filelist.sgml.
  68   Follow the naming convention, or you'll confuse generate_history.pl.
  69
  70   The reason for splitting the release notes this way is so that appropriate
  71   subsets can easily be copied into back branches.
  72 -->
  73 &release-8.4;
  74 &release-8.3;
  75 &release-8.2;
  76 &release-8.1;
  77 &release-8.0;
  78 &release-7.4;
  79 &release-old;
  80
  81 </appendix>