<!entity p-intro SYSTEM "privoxy.sgml">
<!entity history SYSTEM "history.sgml">
<!entity seealso SYSTEM "seealso.sgml">
-<!entity p-version "3.0.27">
-<!entity p-status "UNRELEASED">
-<!entity % p-not-stable "INCLUDE">
-<!entity % p-stable "IGNORE">
+<!entity p-version "3.0.29">
+<!entity p-status "stable">
+<!entity % p-not-stable "IGNORE">
+<!entity % p-stable "INCLUDE">
<!entity % p-text "IGNORE"> <!-- define we are not a text only doc -->
<!entity % p-doc "INCLUDE"> <!-- and we are a formal doc -->
<!entity % seealso-extra "INCLUDE"> <!-- extra stuff from seealso.sgml -->
Purpose : developer manual
- Copyright (C) 2001-2018 Privoxy Developers https://www.privoxy.org/
+ Copyright (C) 2001-2020 Privoxy Developers https://www.privoxy.org/
See LICENSE.
========================================================================
<!-- Completely the wrong markup, but very little is allowed -->
<!-- in this part of an article. FIXME -->
<ulink url="https://www.privoxy.org/user-manual/copyright.html">Copyright</ulink>
- &my-copy; 2001-2018 by
+ &my-copy; 2001-2020 by
<ulink url="https://www.privoxy.org/">Privoxy Developers</ulink>
</subscript>
</pubdate>
<para>
The first step is to join the <ulink
url="https://lists.privoxy.org/mailman/listinfo/privoxy-devel">privoxy-devel mailing list</ulink>.
- You can submit your ideas or, even better, patches. Patches are best
- submitted to the Sourceforge tracker set up for this purpose, but
- can be sent to the list for review too.
+ You can submit your ideas or, even better, patches.
+ Patches can also be submitted to the
+ <ulink url="https://sourceforge.net/p/ijbswa/patches/">Sourceforge patch tracker</ulink>.
</para>
<para>
- You will also need to have a git package installed, which will
- entail having ssh installed as well, in order to access the git repository.
+ You will also need to have a git package installed,
+ in order to access the git repository.
Having the GNU build tools is also going to be important (particularly,
autoconf and gmake).
</para>
<sect2 id="gitaccess"><title>Access to Git</title>
<para>
The project's Git repository is hosted at the
- <ulink url="https://privoxy.org/">Privoxy site.</ulink>
- The Git repository URL is
- <literal>ssh://git@git.privoxy.org:23/git/privoxy.git</literal>,
- the central repository is called <literal>privoxy</literal>, and the
+ <ulink url="https://privoxy.org/">Privoxy website</ulink>.
+ For Privoxy team members with push privileges the Git repository URL is
+ <literal>ssh://git@git.privoxy.org:23/git/privoxy.git</literal>.
+ </para>
+ <para>
+ Contributors without push privileges can
+ <quote>git clone https://www.privoxy.org/git/privoxy.git</quote>.
+ </para>
+ <para>
+ The central repository is called <literal>privoxy</literal>, and the
source branch is called <literal>master</literal>. Subfolders exist
within the project for target-dependent build and packaging tools, each
including the name of the target operating system in their name (e.g.
<para>
Note that near a major public release, we get more cautious.
There is always the possibility to submit a patch to the <ulink
- url="https://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse">patch
+ url="https://sourceforge.net/p/ijbswa/patches/">patch
tracker</ulink> instead.
</para>
</listitem>
Alternately, proposed changes can be submitted as patches output by
<literal>git format-patch</literal> to the privoxy-devel mailing list
or alternatively to the patch tracker on Sourceforge:
- <ulink url="https://sourceforge.net/tracker/?group_id=11118&atid=311118">
- https://sourceforge.net/tracker/?group_id=11118&atid=311118</ulink>.
+ <ulink url="https://sourceforge.net/p/ijbswa/patches/">
+ https://sourceforge.net/p/ijbswa/patches/</ulink>.
Then ask for peer review.
</para>
</listitem>
<para>
Some text goes here.
</para>
- </literallayout>
+</literallayout>
<para>
Tags marking individual words, or few words, should be in-line:
</para>
<literallayout>
Just to <emphasis>emphasize</emphasis>, some text goes here.
- </literallayout>
+</literallayout>
</listitem>
<listitem>
<para>
</para>
</itemizedlist>
</para>
- </literallayout>
+</literallayout>
<para>
This makes it easier to find the text amongst the tags ;-)
</para>
the finished doc at that point.
</para>
</listitem>
+
<listitem>
<para>
Commonly used <quote>internal entities</quote>:
</listitem>
<listitem>
<para>
+ <!-- FIXME this is not the way it works anymore -->
Y, the version minor, represents the branch within the major version.
At any point in time, there are two branches being maintained:
The stable branch, with an even minor, say, 2N, in which no functionality is
<listitem>
<para>
Z, the point or sub version, represents a release of the software within a branch.
- It is therefore incremented immediately before each code freeze.
+ It is therefore incremented immediately after each software release.
+ <!-- FIXME this is not the way it works any more
In development branches, only the even point versions correspond to actual releases,
while the odd ones denote the evolving state of the sources on Git in between.
It follows that Z is odd on Git in development branches most of the time. There, it gets
increased to an even number immediately before a code freeze, and is increased to an odd
number again immediately thereafter.
This ensures that builds from Git snapshots are easily distinguished from released versions.
+ didn't Fabian get rid of the even=stable, odd=dev convention for release numbering? -->
The point version is reset to zero when the minor changes.
</para>
<para>
</sect2>
<sect2 id="beforerelease">
- <title>Before the Release: Freeze</title>
+ <title>Before the Release</title>
<para>
The following <emphasis>must be done by one of the
developers</emphasis> prior to each new release.
</para>
- <itemizedlist>
- <listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
Make sure that everybody who has worked on the code in the last
couple of days has had a chance to yell <quote>no!</quote> in case
they have pending changes/fixes in their pipelines. Announce the
freeze so that nobody will interfere with last minute changes.
- </para>
+ </para>
</listitem>
<listitem>
<para>
- Increment the version number (point from odd to even in development
- branches!) in <filename>configure.in</filename> and update the code
- status (CODE_STATUS="xxx") to one of "alpha", "beta" or "stable".
- Rebuild configure and GNUMakefile to make sure the updated values are
- being used.
+ Update the code status (CODE_STATUS="xxx") in configure.in to one of
+ "alpha", "beta" or "stable".
</para>
</listitem>
<listitem>
<para>
- Use the dok-release target to update the sgml documentation source files.
+ Rebuild configure and GNUMakefile to make sure the updated values are being used.
+ </para>
+
+ <programlisting>
+$ autoheader && autoconf # rebuild configure
+$ ./configure # rebuild GNUmakefile
+</programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <command>make dok-release</command> to update the sgml documentation source files.
</para>
</listitem>
<listitem>
</listitem>
<listitem>
<para>
- All documentation should be rebuild after the version bump.
+ Create the change log:
+ </para>
+ <programlisting>
+ $ git tag
+ # to see the tags
+ $ git log [last release tag]..HEAD > /tmp/log
+ # get the commit log since the last release
+ $ utils/makeChangeLog /tmp/log > /tmp/change.log
+ # reformat the commit log
+</programlisting>
+ <para>
+ Edit <filename>/tmp/change.log</filename> to remove trivial
+ changes and group the changes under general headings like:
+ </para>
+ <programlisting>
+- Bug fixes:
+- Action file improvements:
+- Filter file improvements:
+- General improvements:
+- Documentation improvements:
+- Build system improvements:
+- Code cleanups:
+- Privoxy-Log-Parser:
+- Privoxy-Regression-Test:
+</programlisting>
+ <para>
+ Add the contents of <filename>/tmp/change.log</filename> to the
+ start of <filename>ChangeLog</filename> and re-create
+ <filename>doc/source/changelog.sgml</filename>:
+ </para>
+ <programlisting>
+ $ utils/changelog2doc.pl /tmp/change.log >| doc/source/changelog.sgml
+</programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ All developers should look at the <filename>ChangeLog</filename> and
+ make sure noteworthy changes are referenced.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ All documentation should be rebuilt:
+ <programlisting>
+ $ make man
+ $ make dok
+ $ make dok-man
+ $ make dok-tidy
+ $ make config-file
+</programlisting>
Finished docs should be then be committed to Git (for those
without the ability to build these). Some docs may require
rather obscure processing tools. <filename>config</filename>,
the man page (and the html version of the man page)
fall in this category. README, the man page, AUTHORS, and config
should all also be committed to Git for other packagers. The
- formal docs should be uploaded to the webserver. See the
- Section "Updating the webserver" in this manual for details.
+ formal docs should be uploaded to the webserver. See the section
+ <ulink url="webserver-update.html">"Updating the webserver"</ulink>
+ in this manual for details.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>Commit all files that were changed in the above steps!</emphasis>
</para>
</listitem>
<listitem>
target for this at this time!!! It needs to be done manually.
</para>
</listitem>
- <listitem>
- <para>
- All developers should look at the <filename>ChangeLog</filename> and
- make sure noteworthy changes are referenced.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>Commit all files that were changed in the above steps!</emphasis>
- </para>
- </listitem>
<listitem>
<para>
Tag all files in Git with the version number with
- <quote><command>cvs tag v_X_Y_Z</command></quote>.
+ <quote><command>git tag v_X_Y_Z</command></quote>.
Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
</para>
</listitem>
- <listitem>
- <para>
- If the release was in a development branch, increase the point version
- from even to odd (X.Y.(Z+1)) again in <filename>configure.in</filename> and
- commit your change.
- </para>
- </listitem>
<listitem>
<para>
On the webserver, copy the user manual to a new top-level directory
<programlisting>
mkdir dist # delete or choose different name if it already exists
cd dist
- cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
+ git clone https://www.privoxy.org/git/privoxy.git
+ cd privoxy
+ git checkout v_X_Y_Z
</programlisting>
<para>
be reset to one if this is the first RPM for
<replaceable class="parameter">dist</replaceable> which is built from version
X.Y.Z. Check the
- <ulink url="https://sourceforge.net/project/showfiles.php?group_id=11118">file
+ <ulink url="https://sourceforge.net/projects/ijbswa/files/">file
list</ulink> if unsure. Else, it must be set to the highest already available RPM
release number for that version plus one.
</para>
</para>
</sect3>
- <sect3 id="newrelease-os2"><title>OS/2</title>
- <para>
- First, <emphasis>make sure that you have freshly exported the right
- version into an empty directory</emphasis>. (See "Building and releasing
- packages" above). Then get the OS/2 Setup module:
- </para>
- <programlisting>
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
-</programlisting>
- <para>
- You will need a mix of development tools.
- The main compilation takes place with IBM Visual Age C++.
- Some ancillary work takes place with GNU tools, available from
- various sources like hobbes.nmsu.edu.
- Specificially, you will need <filename>autoheader</filename>,
- <filename>autoconf</filename> and <filename>sh</filename> tools.
- The packaging takes place with WarpIN, available from various sources, including
- its home page: <ulink url="http://www.xworkplace.org/">xworkplace</ulink>.
- </para>
- <para>
- Change directory to the <filename>os2setup</filename> directory.
- Edit the os2build.cmd file to set the final executable filename.
- For example,
- </para>
- <programlisting>
- installExeName='privoxyos2_setup_X.Y.Z.exe'
-</programlisting>
- <para>
- Next, edit the <filename>IJB.wis</filename> file so the release number matches
- in the <filename>PACKAGEID</filename> section:
- </para>
- <programlisting>
- PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
-</programlisting>
- <para>
- You're now ready to build. Run:
- </para>
- <programlisting>
- os2build
-</programlisting>
- <para>
- You will find the WarpIN-installable executable in the
- <filename>./files</filename> directory. Upload this anonymously to
- <filename>uploads.sourceforge.net/incoming</filename>, create a release
- for it, and you're done. Use the release notes and Change Log from the
- source tarball package.
- </para>
- </sect3>
-
<sect3 id="newrelease-solaris"><title>Solaris</title>
<para>
Login to Sourceforge's compilefarm via ssh:
</para>
</sect3>
- <sect3 id="newrelease-windows"><title>Windows</title>
+ <sect3 id="NEWRELEASE-WINDOWS"><title>Windows</title>
+ <!-- so annoying: docbook generated ids are UPPERCASE so
+ links to "whatever.html#idtag" DO NOT WORK!!
+ They have to be "whatever.html#IDTAG".
+ So be consistent and use uppercase on the definition.
+ -->
<para>
- Use the <ulink url="http://www.fruitbat.org/Cygwin/index.html#cygwincirca">
- Cygwin Time Machine</ulink> to install the last 1.5 version of Cygwin.
- Run the following commands from within the Cygwin 1.5 bash shell.
+ Note that the docbook generated files might need some hand editing,
+ so the Windows build makefile does not rebuild the docs.
</para>
+
<para>
First, <emphasis>make sure that you have freshly exported the right
version into an empty directory</emphasis>. (See "Building and releasing
- packages" above). Then get the Windows setup module:
+ packages" above).
+ <!-- XXX ??? are we still basing releases off a tarball???
+ -->
</para>
- <programlisting>
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
-</programlisting>
<para>
Then you can build the package. This is fully automated, and is
- controlled by <filename>winsetup/GNUmakefile</filename>.
+ controlled by <filename>windows/GNUmakefile</filename>.
All you need to do is:
</para>
<programlisting>
- cd winsetup
+ cd windows
make
</programlisting>
<para>
Now you can manually rename <filename>privoxy_setup.exe</filename> to
- <filename>privoxy_setup_X_Y_Z.exe</filename>, and upload it to
- SourceForge. When releasing the package on SourceForge, use the release notes
+ <filename>privoxy_setup_X.Y.Z.exe</filename>, and the <filename>build</filename>
+ directory to <filename>privoxy_X.Y.Z</filename>.
+ Create a .zip file of the newly renamed <filename>privoxy_X.Y.Z</filename> directory,
+ GPG sign the installer and zip file,
+ </para>
+ <programlisting>
+ $ gpg --armor --detach --sign <filename>privoxy_setup_X.Y.Z.exe</filename>
+ $ gpg --armor --detach --sign <filename>privoxy_X.Y.Z.zip</filename>
+</programlisting>
+ <para>
+ and upload the files to SourceForge.
+ </para>
+
+ <para>
+ When releasing the package on SourceForge, use the release notes
and Change Log from the source tarball package.
</para>
</sect3>
to SourceForge, and go through the release steps. The upload
is done via FTP:
</para>
- <itemizedlist>
- <listitem>
-
Upload to: <ulink url="ftp://upload.sourceforge.net/incoming">ftp://upload.sourceforge.net/incoming</ulink>
- </para>
- </listitem>
- <listitem>
- user: <literal>anonymous</literal>
- </para>
- </listitem>
- <listitem>
- password: <literal>ijbswa-developers@lists.sourceforge.net</literal>
- </para>
- </listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Upload to: <ulink url="ftp://upload.sourceforge.net/incoming">ftp://upload.sourceforge.net/incoming</ulink>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ user: <literal>anonymous</literal>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ password: <literal>ijbswa-developers@lists.sourceforge.net</literal>
+ </para>
+ </listitem>
+ </itemizedlist>
<para>
Or use the <command>make</command> targets as described above.
</para>
<para>
- Once this done go to <ulink
- url="https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
- >https://sourceforge.net/project/admin/editpackages.php?group_id=11118</ulink>,
+ Once this done go to
+ <ulink url="https://sourceforge.net/project/admin/editpackages.php?group_id=11118">
+ https://sourceforge.net/project/admin/editpackages.php?group_id=11118</ulink>,
making sure you are logged in. Find your target platform in the
second column, and click <literal>Add Release</literal>. You will
then need to create a new release for your package, using the format
<title>After the Release</title>
<para>
When all (or: most of the) packages have been uploaded and made available,
- send an email to the <ulink url="mailto:privoxy-announce@lists.privoxy.org">announce
- mailing list</ulink>, Subject: "Version X.Y.Z available for download". Be sure to
+ send an email to the
+ <ulink url="mailto:privoxy-announce@lists.privoxy.org">announce mailing
+ list</ulink>, Subject: "Version X.Y.Z available for download". Be sure to
include the
- <ulink url="https://sourceforge.net/project/showfiles.php?group_id=11118">download
- location</ulink>, the release notes and the Changelog. Also, post an
+ <ulink url="https://sourceforge.net/projects/ijbswa/files/">
+ download location</ulink>, the release notes and the Changelog. Also, post an
updated News item on the project page Sourceforge, and update the Home
page and docs linked from the Home page (see below). Other news sites
and release oriented sites, such as Freshmeat, should also be notified.
</para>
+ <para>
+ Then update the source code for the next version to be released:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Increment the version number and change the code status to "UNRELEASED"
+ in <filename>configure.in</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Rebuild configure (<quote><command>autoheader && autoconf</command></quote>)
+ and GNUMakefile (<quote><command>./configure</command></quote>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <quote><command>make dok-release</command></quote> to update the sgml documentation source files.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Commit all your changes.
+ </para>
+ </listitem>
+ </itemizedlist>
+
</sect2>
</sect1>
projects / privoxy.git / blobdiff