<!entity p-intro SYSTEM "privoxy.sgml">
<!entity history SYSTEM "history.sgml">
<!entity seealso SYSTEM "seealso.sgml">
-<!entity p-version "3.0.27">
+<!entity p-version "3.0.29">
<!entity p-status "UNRELEASED">
<!entity % p-not-stable "INCLUDE">
<!entity % p-stable "IGNORE">
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>
can be sent to the list for review too.
</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.
</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.
</listitem>
<listitem>
<para>
- All documentation should be rebuild after the code status has been changed.
+ 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>,
in this manual for details.
</para>
</listitem>
+ <listitem>
+ <para>
+ <emphasis>Commit all files that were changed in the above steps!</emphasis>
+ </para>
+ </listitem>
<listitem>
<para>
The <citetitle>User Manual</citetitle> is also used for context
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>
projects / privoxy.git / blobdiff