/usr/share/doc/slony1-2-doc/adminguide/releasechecklist.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
> Release Checklist </TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:slony1-general@lists.slony.info"><LINK
REL="HOME"
TITLE="Slony-I 2.1.4 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Appendix"
HREF="appendix.html"><LINK
REL="PREVIOUS"
TITLE="Appendix"
HREF="appendix.html"><LINK
REL="NEXT"
TITLE="Using Slonik"
HREF="usingslonik.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2014-02-06T00:06:49"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> 2.1.4 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="appendix.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="appendix.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 7. Appendix</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="appendix.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="usingslonik.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="RELEASECHECKLIST"
>7.2. Release Checklist</A
></H1
><A
NAME="AEN9810"
></A
><P
> Here are things that should be done whenever a release is prepared:</P
><P
></P
><UL
><LI
><P
>Positive build reports for each supported platform -
although it is arguably less necessary for a comprehensive list if we
are releasing a minor upgrade </P
></LI
><LI
><P
>Some kind of Standard Test Plan</P
></LI
><LI
><P
> If the release modified the set of version-specific
SQL files in <TT
CLASS="FILENAME"
>src/backend</TT
>
(<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>e.g.</I
></SPAN
> - it added a new
<TT
CLASS="FILENAME"
>slony1_base.v83.sql</TT
> or
<TT
CLASS="FILENAME"
>slony1_funcs.v83.sql</TT
>), or if we have other
changes to the shape of <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> version support, the function
<CODE
CLASS="FUNCTION"
>load_slony_functions() </CODE
> in
<TT
CLASS="FILENAME"
>src/slonik/slonik.c</TT
> needs to be revised to
reflect the new shape of things.</P
></LI
><LI
><P
> The new release needs to be added to function
<CODE
CLASS="FUNCTION"
>upgradeSchema(text)</CODE
> in
<TT
CLASS="FILENAME"
>src/backend/slony1_funcs.sql</TT
>. </P
><P
> This takes place in a <SPAN
CLASS="QUOTE"
>"cross-branch"</SPAN
> fashion; if
we add version 1.1.9, in the 1.1 branch, then version 1.1.9 needs to
be added to the 1.2 branch as well as to later branches
(<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>e.g.</I
></SPAN
> - 1.3, 1.4, HEAD).  Earlier branches will
normally not need to be made aware of versions added to later
branches. </P
><P
> This was not true for version 2 - version 2.0 was different
enough from earlier versions that we rejected having a direct upgrade
from 1.x to 2.0, so there are <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>no</I
></SPAN
> versions in 1.x
branches in <CODE
CLASS="FUNCTION"
>upgradeSchema(text)</CODE
> for <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
>
version 2.0. </P
></LI
><LI
><P
>Binary RPM packages</P
></LI
><LI
><P
>If the release is a <SPAN
CLASS="QUOTE"
>".0"</SPAN
> one, we need to
open a new STABLE branch</P
><P
> <TT
CLASS="COMMAND"
> git checkout HEAD</TT
></P
><P
> <TT
CLASS="COMMAND"
> git checkout -b REL_3_0_STABLE</TT
></P
></LI
><LI
><P
>Tag with the release ID. For version 1.1.2, this
would be <TT
CLASS="ENVAR"
>REL_1_1_2 </TT
></P
><P
> <TT
CLASS="COMMAND"
> git tag -a REL_1_1_2 </TT
></P
></LI
><LI
><P
>Check out an exported copy via:
<TT
CLASS="COMMAND"
>git archive REL_1_1_2  -o /tmp/slony1-engine-1.0.2.tar </TT
> </P
></LI
><LI
><P
>Run <SPAN
CLASS="APPLICATION"
>autoconf</SPAN
> so as to
regenerate <TT
CLASS="FILENAME"
>configure</TT
> from
<TT
CLASS="FILENAME"
>configure.ac</TT
></P
></LI
><LI
><P
>Purge directory <TT
CLASS="FILENAME"
>autom4te.cache</TT
> so it is not included in the build  </P
><P
> Does not need to be done by hand - the later <TT
CLASS="COMMAND"
> make distclean </TT
> step does this for you. </P
></LI
><LI
><P
> Run <TT
CLASS="FILENAME"
>tools/release_checklist.sh</TT
> </P
><P
> This does a bunch of consistency checks to make sure that
various files that are supposed to contain version numbers contain
consistent values.</P
></LI
><LI
><P
>For instance, configure should contain, for release 1.1.2:</P
></LI
><LI
><P
>PACKAGE_VERSION=REL_1_1_2</P
></LI
><LI
><P
>PACKAGE_STRING=slony1 REL_1_1_2</P
></LI
></UL
><P
></P
><UL
><LI
><P
> <TT
CLASS="FILENAME"
> config.h.in </TT
> needs to contain the version
number in two forms; the definitions for
<TT
CLASS="ENVAR"
>SLONY_I_VERSION_STRING</TT
> and
<TT
CLASS="ENVAR"
>SLONY_I_VERSION_STRING_DEC</TT
> both need to be
updated. </P
></LI
><LI
><P
> <TT
CLASS="FILENAME"
>src/backend/slony1_funcs.sql</TT
> has
major/minor/patch versions in functions
<CODE
CLASS="FUNCTION"
>slonyVersionMajor()</CODE
>,
<CODE
CLASS="FUNCTION"
>slonyVersionMinor()</CODE
>, and
<CODE
CLASS="FUNCTION"
>slonyVersionPatchlevel()</CODE
>.  These need to be
assigned <SPAN
CLASS="QUOTE"
>"by hand"</SPAN
> at this point.</P
></LI
><LI
><P
> It sure would be nice if more of these could be assigned
automatically, somehow.</P
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Don't</I
></SPAN
> commit the new
<TT
CLASS="FILENAME"
>configure</TT
>; we shouldn't be tracking this in Git.</P
></LI
><LI
><P
>make sure that the generated files from .l and .y are
created, for example <TT
CLASS="FILENAME"
>slony/conf-file.[ch]</TT
> </P
><P
> Currently this is best done by issuing <TT
CLASS="COMMAND"
> ./configure &#38;&#38;
make all &#38;&#38; make clean</TT
> but that is a somewhat ugly approach.</P
><P
> Slightly better may be <TT
CLASS="COMMAND"
> ./configure &#38;&#38; make
src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c </TT
></P
></LI
><LI
><P
> Make sure that generated Makefiles and such from the
previous step(s) are removed.</P
><P
> <TT
CLASS="COMMAND"
>make distclean</TT
> will do
that... </P
><P
> Note that <TT
CLASS="COMMAND"
>make distclean</TT
> also clears out
<TT
CLASS="FILENAME"
>autom4te.cache</TT
>, thus obsoleting some former steps
that suggested that it was needful to delete them. </P
></LI
><LI
><P
>Generate HTML tarball, and RTF/PDF, if
possible... Note that the HTML version should include
<TT
CLASS="FILENAME"
>*.html</TT
> (duh!), <TT
CLASS="FILENAME"
>*.jpg</TT
>,
<TT
CLASS="FILENAME"
>*.png</TT
>, and <TT
CLASS="FILENAME"
>*.css</TT
> </P
><P
> Note that, if starting from a <SPAN
CLASS="QUOTE"
>"clean"</SPAN
> copy of the
documentation, in order to properly build the HTML tarball, it is
necessary to run <TT
CLASS="COMMAND"
>make html</TT
>
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>twice</I
></SPAN
>, in order for the document index to be
properly constructed.

<P
></P
></P><UL
><LI
><P
> The first time <TT
CLASS="COMMAND"
>make html</TT
> is run,
the file <TT
CLASS="FILENAME"
>HTML.index</TT
> does not yet exist.</P
><P
> When <SPAN
CLASS="APPLICATION"
>jade</SPAN
> is run, against the
document, a side-effect is to generate
<TT
CLASS="FILENAME"
>HTML.index</TT
>, extracting all index tags from the
<SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> documentation.</P
></LI
><LI
><P
> The second time <TT
CLASS="COMMAND"
>make html</TT
> is run,
<TT
CLASS="FILENAME"
>HTML.index</TT
> is transformed into
<TT
CLASS="FILENAME"
>bookindex.sgml</TT
>, which
<SPAN
CLASS="APPLICATION"
>jade</SPAN
> may then use to generate a nice <A
HREF="bookindex.html"
>index page</A
> indicating all the index entries
included in the documentation tree.</P
></LI
></UL
><P></P
></LI
><LI
><P
>Run <TT
CLASS="COMMAND"
>make clean</TT
> in
<TT
CLASS="FILENAME"
>doc/adminguide</TT
> before generating the tarball in
order that <TT
CLASS="FILENAME"
>bookindex.sgml</TT
> is NOT part of the
tarball </P
></LI
><LI
><P
>Alternatively, delete
<TT
CLASS="FILENAME"
>doc/adminguide/bookindex.sgml </TT
> </P
></LI
><LI
><P
>Rename the directory (<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>e.g.</I
></SPAN
> -
<TT
CLASS="FILENAME"
>slony1-engine</TT
>) to a name based on the release,
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>e.g.</I
></SPAN
> - <TT
CLASS="FILENAME"
>slony1-1.1.2</TT
></P
></LI
><LI
><P
>Generate a tarball - <TT
CLASS="COMMAND"
>tar tfvj
slony1-1.1.2.tar.bz2 slony1-1.1.2 </TT
> </P
></LI
><LI
><P
>Build the administrative documentation, and build a
tarball as <TT
CLASS="FILENAME"
>slony1-1.1.2-html.tar.bz2</TT
></P
><P
> Make sure that the docs are inside a subdir in the tarball.</P
></LI
><LI
><P
>Put these tarballs in a temporary area, and notify
everyone that they should test them out ASAP based on the Standard
Test Plan. </P
></LI
></UL
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="appendix.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="usingslonik.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Appendix</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="appendix.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Using Slonik</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
slony1-2-doc 2.1.4-1ubuntu1 / usr / share / doc / slony1-2-doc / adminguide / releasechecklist.html
