doc/webserver/developer-manual/newrelease.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   2 <HTML
   3 ><HEAD
   4 ><TITLE
   5 >Releasing a New Version</TITLE
   6 ><META
   7 NAME="GENERATOR"
   8 CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
   9 REL="HOME"
  10 TITLE="Privoxy Developer Manual"
  11 HREF="index.html"><LINK
  12 REL="PREVIOUS"
  13 TITLE="Testing Guidelines"
  14 HREF="testing.html"><LINK
  15 REL="NEXT"
  16 TITLE="Update the Webserver"
  17 HREF="webserver-update.html"><LINK
  18 REL="STYLESHEET"
  19 TYPE="text/css"
  20 HREF="../p_doc.css"><META
  21 HTTP-EQUIV="Content-Type"
  22 CONTENT="text/html;
  23 charset=ISO-8859-1"></HEAD
  24 ><BODY
  25 CLASS="SECT1"
  26 BGCOLOR="#EEEEEE"
  27 TEXT="#000000"
  28 LINK="#0000FF"
  29 VLINK="#840084"
  30 ALINK="#0000FF"
  31 ><DIV
  32 CLASS="NAVHEADER"
  33 ><TABLE
  34 SUMMARY="Header navigation table"
  35 WIDTH="100%"
  36 BORDER="0"
  37 CELLPADDING="0"
  38 CELLSPACING="0"
  39 ><TR
  40 ><TH
  41 COLSPAN="3"
  42 ALIGN="center"
  43 >Privoxy Developer Manual</TH
  44 ></TR
  45 ><TR
  46 ><TD
  47 WIDTH="10%"
  48 ALIGN="left"
  49 VALIGN="bottom"
  50 ><A
  51 HREF="testing.html"
  52 ACCESSKEY="P"
  53 >Prev</A
  54 ></TD
  55 ><TD
  56 WIDTH="80%"
  57 ALIGN="center"
  58 VALIGN="bottom"
  59 ></TD
  60 ><TD
  61 WIDTH="10%"
  62 ALIGN="right"
  63 VALIGN="bottom"
  64 ><A
  65 HREF="webserver-update.html"
  66 ACCESSKEY="N"
  67 >Next</A
  68 ></TD
  69 ></TR
  70 ></TABLE
  71 ><HR
  72 ALIGN="LEFT"
  73 WIDTH="100%"></DIV
  74 ><DIV
  75 CLASS="SECT1"
  76 ><H1
  77 CLASS="SECT1"
  78 ><A
  79 NAME="NEWRELEASE"
  80 >6. Releasing a New Version</A
  81 ></H1
  82 ><P
  83 >        When we release versions of <SPAN
  84 CLASS="APPLICATION"
  85 >Privoxy</SPAN
  86 >,
  87         our work leaves our cozy secret lab and has to work in the cold
  88         RealWorld[tm]. Once it is released, there is no way to call it
  89         back, so it is very important that great care is taken to ensure
  90         that everything runs fine, and not to introduce problems in the
  91         very last minute.
  92     </P
  93 ><P
  94 >        So when releasing a new version, please adhere exactly to the
  95         procedure outlined in this chapter.
  96     </P
  97 ><P
  98 >        The following programs are required to follow this process:
  99         <TT
 100 CLASS="FILENAME"
 101 >ssh</TT
 102 >,
 103         <TT
 104 CLASS="FILENAME"
 105 >gmake</TT
 106 > (GNU's version of make), autoconf, git,
 107         a web browser.
 108     </P
 109 ><DIV
 110 CLASS="SECT2"
 111 ><H2
 112 CLASS="SECT2"
 113 ><A
 114 NAME="VERSIONNUMBERS"
 115 >6.1. Version numbers</A
 116 ></H2
 117 ><P
 118 >      First you need to determine which version number the release will have.
 119       <SPAN
 120 CLASS="APPLICATION"
 121 >Privoxy</SPAN
 122 > version numbers consist of three numbers,
 123       separated by dots, like in X.Y.Z (e.g. 3.0.0), where:
 124     </P
 125 ><P
 126 ></P
 127 ><UL
 128 ><LI
 129 ><P
 130 >              X, the version major, is rarely ever changed. It is increased by one if
 131               turning a development branch into stable substantially changes the functionality,
 132               user interface or configuration syntax. Majors 1 and 2 were
 133               <SPAN
 134 CLASS="APPLICATION"
 135 >Junkbuster</SPAN
 136 >, and 3 is the first stable
 137               <SPAN
 138 CLASS="APPLICATION"
 139 >Privoxy</SPAN
 140 > release.
 141             </P
 142 ></LI
 143 ><LI
 144 ><P
 145 >
 146               Y, the version minor, represents the branch within the major version.
 147               At any point in time, there are two branches being maintained:
 148               The stable branch, with an even minor, say, 2N, in which no functionality is
 149               being added and only bug-fixes are made, and 2N+1, the development branch, in
 150               which the further development of <SPAN
 151 CLASS="APPLICATION"
 152 >Privoxy</SPAN
 153 > takes
 154               place.
 155               This enables us to turn the code upside down and inside out, while at the same time
 156               providing and maintaining a stable version.
 157               The minor is reset to zero (and one) when the major is incremented. When a development
 158               branch has matured to the point where it can be turned into stable, the old stable branch
 159               2N is given up (i.e. no longer maintained), the former development branch 2N+1 becomes the
 160               new stable branch 2N+2, and a new development branch 2N+3 is opened.
 161             </P
 162 ></LI
 163 ><LI
 164 ><P
 165 >              Z, the point or sub version, represents a release of the software within a branch.
 166               It is therefore incremented immediately after each software release.
 167
 168               The point version is reset to zero when the minor changes.
 169             </P
 170 ><P
 171 >              Stable branches work a little differently, since there should be
 172               little to no development happening in such branches. Remember,
 173               only bugfixes, which presumably should have had some testing
 174               before being committed. Stable branches will then have their
 175               version reported as <TT
 176 CLASS="LITERAL"
 177 >0.0.0</TT
 178 >, during that period
 179               between releases when changes are being added. This is to denote
 180               that this code is <SPAN
 181 CLASS="emphasis"
 182 ><I
 183 CLASS="EMPHASIS"
 184 >not for release</I
 185 ></SPAN
 186 >. Then
 187               as the release nears, the version is bumped according: e.g.
 188               <TT
 189 CLASS="LITERAL"
 190 >3.0.1 -&#62; 0.0.0 -&#62; 3.0.2</TT
 191 >.
 192             </P
 193 ></LI
 194 ></UL
 195 ><P
 196 >     In summary, the main Git trunk is the development branch where new
 197      features are being worked on for the next stable series. This should
 198      almost always be where the most activity takes place. There is always at
 199      least one stable branch from the trunk, e.g now it is
 200      <TT
 201 CLASS="LITERAL"
 202 >3.0</TT
 203 >, which is only used to release stable versions.
 204      Once the initial *.0 release of the stable branch has been done, then as a
 205      rule, only bugfixes that have had prior testing should be committed to
 206      the stable branch. Once there are enough bugfixes to justify a new
 207      release, the version of this branch is again incremented Example: 3.0.0
 208      -&#62; 3.0.1 -&#62; 3.0.2, etc are all stable releases from within the stable
 209      branch. 3.1.x is currently the main trunk, and where work on 3.2.x is
 210      taking place. If any questions, please post to the devel list
 211      <SPAN
 212 CLASS="emphasis"
 213 ><I
 214 CLASS="EMPHASIS"
 215 >before</I
 216 ></SPAN
 217 > committing to a stable branch!
 218     </P
 219 ><P
 220 >     Developers should remember too that if they commit a bugfix to the stable
 221      branch, this will more than likely require a separate submission to the
 222      main trunk, since these are separate development trees within Git. If you
 223      are working on both, then this would require at least two separate check
 224      outs (i.e main trunk, <SPAN
 225 CLASS="emphasis"
 226 ><I
 227 CLASS="EMPHASIS"
 228 >and</I
 229 ></SPAN
 230 > the stable release branch,
 231      which is <TT
 232 CLASS="LITERAL"
 233 >v_3_0_branch</TT
 234 > at the moment).
 235     </P
 236 ></DIV
 237 ><DIV
 238 CLASS="SECT2"
 239 ><H2
 240 CLASS="SECT2"
 241 ><A
 242 NAME="BEFORERELEASE"
 243 >6.2. Before the Release</A
 244 ></H2
 245 ><P
 246 >       The following <SPAN
 247 CLASS="emphasis"
 248 ><I
 249 CLASS="EMPHASIS"
 250 >must be done by one of the
 251        developers</I
 252 ></SPAN
 253 > prior to each new release.
 254      </P
 255 ><P
 256 ></P
 257 ><UL
 258 ><LI
 259 ><P
 260 >         Make sure that everybody who has worked on the code in the last
 261          couple of days has had a chance to yell <SPAN
 262 CLASS="QUOTE"
 263 >"no!"</SPAN
 264 > in case
 265          they have pending changes/fixes in their pipelines. Announce the
 266          freeze so that nobody will interfere with last minute changes.
 267        </P
 268 ></LI
 269 ><LI
 270 ><P
 271 >         Update the code status (CODE_STATUS="xxx") in <TT
 272 CLASS="FILENAME"
 273 >configure.in</TT
 274 > to one of
 275          "alpha", "beta" or "stable".
 276        </P
 277 ></LI
 278 ><LI
 279 ><P
 280 >         Rebuild configure and GNUMakefile to make sure the updated values are being used.
 281        </P
 282 ><TABLE
 283 BORDER="0"
 284 BGCOLOR="#E0E0E0"
 285 WIDTH="90%"
 286 ><TR
 287 ><TD
 288 ><PRE
 289 CLASS="PROGRAMLISTING"
 290 >  $ autoheader &#38;&#38; autoconf     # rebuild configure
 291   $ ./configure                # rebuild GNUmakefile</PRE
 292 ></TD
 293 ></TR
 294 ></TABLE
 295 ></LI
 296 ><LI
 297 ><P
 298 >        <B
 299 CLASS="COMMAND"
 300 >make dok-release</B
 301 > to update the sgml documentation source files.
 302        </P
 303 ></LI
 304 ><LI
 305 ><P
 306 >        If action file processing has changed and is not backward-compatible,
 307         make sure the "for-privoxy-version=x.y.z" minimum version number in
 308         <TT
 309 CLASS="FILENAME"
 310 >default.action.master</TT
 311 > has been updated:
 312        </P
 313 ><TABLE
 314 BORDER="0"
 315 BGCOLOR="#E0E0E0"
 316 WIDTH="90%"
 317 ><TR
 318 ><TD
 319 ><PRE
 320 CLASS="PROGRAMLISTING"
 321 >  {{settings}}
 322   #############################################################################
 323   #MASTER# COMMENT: The minimum Privoxy version:
 324   for-privoxy-version=3.0.11</PRE
 325 ></TD
 326 ></TR
 327 ></TABLE
 328 ></LI
 329 ><LI
 330 ><P
 331 >        Create the change log:
 332        </P
 333 ><TABLE
 334 BORDER="0"
 335 BGCOLOR="#E0E0E0"
 336 WIDTH="90%"
 337 ><TR
 338 ><TD
 339 ><PRE
 340 CLASS="PROGRAMLISTING"
 341 >  $ git tag
 342   #   to see the tags
 343   $ git log [last release tag]..master &gt; /tmp/log
 344   #   get the commit log since the last release
 345   $ utils/makeChangeLog /tmp/log &gt; /tmp/change.log
 346   #   reformat the commit log</PRE
 347 ></TD
 348 ></TR
 349 ></TABLE
 350 ><P
 351 >        Edit <TT
 352 CLASS="FILENAME"
 353 >/tmp/change.log</TT
 354 > to remove trivial
 355         changes and group the changes under general headings like:
 356        </P
 357 ><TABLE
 358 BORDER="0"
 359 BGCOLOR="#E0E0E0"
 360 WIDTH="90%"
 361 ><TR
 362 ><TD
 363 ><PRE
 364 CLASS="PROGRAMLISTING"
 365 >  - Bug fixes:
 366   - Action file improvements:
 367   - Filter file improvements:
 368   - General improvements:
 369   - Documentation improvements:
 370   - Build system improvements:
 371   - Code cleanups:
 372   - Privoxy-Log-Parser:
 373   - Privoxy-Regression-Test:</PRE
 374 ></TD
 375 ></TR
 376 ></TABLE
 377 ><P
 378 >        Add the contents of <TT
 379 CLASS="FILENAME"
 380 >/tmp/change.log</TT
 381 > to the
 382         start of <TT
 383 CLASS="FILENAME"
 384 >ChangeLog</TT
 385 > and re-create
 386         <TT
 387 CLASS="FILENAME"
 388 >doc/source/changelog.sgml</TT
 389 >:
 390        </P
 391 ><TABLE
 392 BORDER="0"
 393 BGCOLOR="#E0E0E0"
 394 WIDTH="90%"
 395 ><TR
 396 ><TD
 397 ><PRE
 398 CLASS="PROGRAMLISTING"
 399 >  $ utils/changelog2doc.pl /tmp/change.log &gt;| doc/source/changelog.sgml</PRE
 400 ></TD
 401 ></TR
 402 ></TABLE
 403 ></LI
 404 ><LI
 405 ><P
 406 >        All developers should look at the <TT
 407 CLASS="FILENAME"
 408 >ChangeLog</TT
 409 > and
 410         make sure noteworthy changes are referenced.
 411        </P
 412 ></LI
 413 ><LI
 414 ><P
 415 >        Update the announcement at <TT
 416 CLASS="FILENAME"
 417 >doc/webserver/announce.txt</TT
 418 >.
 419        </P
 420 ></LI
 421 ><LI
 422 ><P
 423 >        All documentation should be rebuilt:
 424        <TABLE
 425 BORDER="0"
 426 BGCOLOR="#E0E0E0"
 427 WIDTH="90%"
 428 ><TR
 429 ><TD
 430 ><PRE
 431 CLASS="PROGRAMLISTING"
 432 >  $ make man
 433   $ make dok
 434   $ make dok-man
 435   $ make dok-tidy
 436   $ make config-file</PRE
 437 ></TD
 438 ></TR
 439 ></TABLE
 440 >
 441         Finished docs should be then be committed to Git (for those
 442         without the ability to build these). Some docs may require
 443         rather obscure processing tools. <TT
 444 CLASS="FILENAME"
 445 >config</TT
 446 >,
 447         the man page (and the html version of the man page)
 448         fall in this category. README, the man page, AUTHORS, and config
 449         should all also be committed to Git for other packagers. The
 450         formal docs should be uploaded to the webserver. See the section
 451         <A
 452 HREF="webserver-update.html"
 453 TARGET="_top"
 454 >"Updating the webserver"</A
 455 >
 456         in this manual for details.
 457        </P
 458 ></LI
 459 ><LI
 460 ><P
 461 >        <SPAN
 462 CLASS="emphasis"
 463 ><I
 464 CLASS="EMPHASIS"
 465 >Commit all files that were changed in the above steps!</I
 466 ></SPAN
 467 >
 468        </P
 469 ></LI
 470 ><LI
 471 ><P
 472 >         The <I
 473 CLASS="CITETITLE"
 474 >User Manual</I
 475 > is also used for context
 476          sensitive help for the CGI editor. This is version sensitive, so that
 477          the user will get appropriate help for his/her release. So with
 478          each release a fresh version should be uploaded to the webserver
 479          (this is in addition to the main <I
 480 CLASS="CITETITLE"
 481 >User Manual</I
 482 >
 483          link from the main page since we need to keep manuals for various
 484          versions available). The CGI pages will link to something like
 485          <TT
 486 CLASS="LITERAL"
 487 >https://www.privoxy.org/$(VERSION)/user-manual/</TT
 488 >. This
 489          needs to be updated for each new release and is done with the
 490          <SPAN
 491 CLASS="QUOTE"
 492 >"webserver"</SPAN
 493 > target.
 494        </P
 495 ></LI
 496 ><LI
 497 ><P
 498 >        Tag all files in Git with the version number with
 499         <SPAN
 500 CLASS="QUOTE"
 501 >"<B
 502 CLASS="COMMAND"
 503 >git tag -s v_X_Y_Z</B
 504 >"</SPAN
 505 >.
 506         Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
 507        </P
 508 ></LI
 509 ><LI
 510 ><P
 511 >        Push the tag to the remote with
 512         <SPAN
 513 CLASS="QUOTE"
 514 >"<B
 515 CLASS="COMMAND"
 516 >git push origin v_X_Y_Z</B
 517 >"</SPAN
 518 >.
 519        </P
 520 ></LI
 521 ><LI
 522 ><P
 523 >        On the webserver, copy the user manual to a new top-level directory
 524         called <TT
 525 CLASS="FILENAME"
 526 >X.Y.Z</TT
 527 >. This ensures that help links from the CGI
 528         pages, which have the version as a prefix, will go into the right version of the manual.
 529         If this is a development branch release, also symlink <TT
 530 CLASS="FILENAME"
 531 >X.Y.(Z-1)</TT
 532 >
 533         to <TT
 534 CLASS="FILENAME"
 535 >X.Y.Z</TT
 536 > and <TT
 537 CLASS="FILENAME"
 538 >X.Y.(Z+1)</TT
 539 > to
 540         <TT
 541 CLASS="FILENAME"
 542 >.</TT
 543 > (i.e. dot).
 544        </P
 545 ></LI
 546 ></UL
 547 ></DIV
 548 ><DIV
 549 CLASS="SECT2"
 550 ><H2
 551 CLASS="SECT2"
 552 ><A
 553 NAME="THERELEASE"
 554 >6.3. Building and Releasing the Packages</A
 555 ></H2
 556 ><P
 557 >      Now the individual packages can be built and released. Note that for
 558       GPL reasons the first package to be released is always the source tarball.
 559      </P
 560 ><P
 561 >      For <SPAN
 562 CLASS="emphasis"
 563 ><I
 564 CLASS="EMPHASIS"
 565 >all</I
 566 ></SPAN
 567 > types of packages, including the source tarball,
 568       <SPAN
 569 CLASS="emphasis"
 570 ><I
 571 CLASS="EMPHASIS"
 572 >you must make sure that you build from clean sources by exporting
 573       the right version from Git into an empty directory</I
 574 ></SPAN
 575 > (just press return when
 576       asked for a password):
 577      </P
 578 ><TABLE
 579 BORDER="0"
 580 BGCOLOR="#E0E0E0"
 581 WIDTH="100%"
 582 ><TR
 583 ><TD
 584 ><PRE
 585 CLASS="PROGRAMLISTING"
 586 >  mkdir dist # delete or choose different name if it already exists
 587   cd dist
 588   git clone https://www.privoxy.org/git/privoxy.git
 589   cd privoxy
 590   git checkout v_X_Y_Z</PRE
 591 ></TD
 592 ></TR
 593 ></TABLE
 594 ><P
 595 >     <SPAN
 596 CLASS="emphasis"
 597 ><I
 598 CLASS="EMPHASIS"
 599 >Do NOT change</I
 600 ></SPAN
 601 > a single bit, including, but not limited to
 602      version information after export from Git. This is to make sure that
 603      all release packages, and with them, all future bug reports, are based
 604      on exactly the same code.
 605     </P
 606 ><DIV
 607 CLASS="WARNING"
 608 ><P
 609 ></P
 610 ><TABLE
 611 CLASS="WARNING"
 612 BORDER="1"
 613 WIDTH="100%"
 614 ><TR
 615 ><TD
 616 ALIGN="CENTER"
 617 ><B
 618 >Warning</B
 619 ></TD
 620 ></TR
 621 ><TR
 622 ><TD
 623 ALIGN="LEFT"
 624 ><P
 625 >      Every significant release of Privoxy has included at least one
 626       package that either had incorrect versions of files, missing files,
 627       or incidental leftovers from a previous build process that gave
 628       unknown numbers of users headaches to try to figure out what was
 629       wrong. PLEASE, make sure you are using pristene sources, and are
 630       following the prescribed process!
 631      </P
 632 ></TD
 633 ></TR
 634 ></TABLE
 635 ></DIV
 636 ><P
 637 >     Please find additional instructions for the source tarball and the
 638      individual platform dependent binary packages below. And details
 639      on the Sourceforge release process below that.
 640     </P
 641 ><DIV
 642 CLASS="SECT3"
 643 ><H3
 644 CLASS="SECT3"
 645 ><A
 646 NAME="PACK-GUIDELINES"
 647 >6.3.1. Note on Privoxy Packaging</A
 648 ></H3
 649 ><P
 650 >      Please keep these general guidelines in mind when putting together
 651       your package. These apply to <SPAN
 652 CLASS="emphasis"
 653 ><I
 654 CLASS="EMPHASIS"
 655 >all</I
 656 ></SPAN
 657 > platforms!
 658      </P
 659 ><P
 660 ></P
 661 ><UL
 662 ><LI
 663 ><P
 664 >          <SPAN
 665 CLASS="APPLICATION"
 666 >Privoxy</SPAN
 667 > <SPAN
 668 CLASS="emphasis"
 669 ><I
 670 CLASS="EMPHASIS"
 671 >requires</I
 672 ></SPAN
 673 >
 674           write access to: all <TT
 675 CLASS="FILENAME"
 676 >*.action</TT
 677 > files, all
 678           logfiles, and the <TT
 679 CLASS="FILENAME"
 680 >trust</TT
 681 > file. You will
 682           need to determine the best way to do this for your platform.
 683         </P
 684 ></LI
 685 ><LI
 686 ><P
 687 >          Please include up to date documentation. At a bare minimum:
 688         </P
 689 ><P
 690 ></P
 691 ><TABLE
 692 BORDER="0"
 693 ><TBODY
 694 ><TR
 695 ><TD
 696 >          <TT
 697 CLASS="FILENAME"
 698 >LICENSE</TT
 699 > (top-level directory)
 700          </TD
 701 ></TR
 702 ></TBODY
 703 ></TABLE
 704 ><P
 705 ></P
 706 ><P
 707 ></P
 708 ><TABLE
 709 BORDER="0"
 710 ><TBODY
 711 ><TR
 712 ><TD
 713 >          <TT
 714 CLASS="FILENAME"
 715 >README</TT
 716 > (top-level directory)
 717          </TD
 718 ></TR
 719 ></TBODY
 720 ></TABLE
 721 ><P
 722 ></P
 723 ><P
 724 ></P
 725 ><TABLE
 726 BORDER="0"
 727 ><TBODY
 728 ><TR
 729 ><TD
 730 >          <TT
 731 CLASS="FILENAME"
 732 >AUTHORS</TT
 733 > (top-level directory)
 734          </TD
 735 ></TR
 736 ></TBODY
 737 ></TABLE
 738 ><P
 739 ></P
 740 ><P
 741 ></P
 742 ><TABLE
 743 BORDER="0"
 744 ><TBODY
 745 ><TR
 746 ><TD
 747 >          <TT
 748 CLASS="FILENAME"
 749 >man page</TT
 750 > (top-level directory, Unix-like
 751           platforms only)
 752          </TD
 753 ></TR
 754 ></TBODY
 755 ></TABLE
 756 ><P
 757 ></P
 758 ><P
 759 ></P
 760 ><TABLE
 761 BORDER="0"
 762 ><TBODY
 763 ><TR
 764 ><TD
 765 >          <TT
 766 CLASS="FILENAME"
 767 >The User Manual</TT
 768 > (doc/webserver/user-manual/)
 769          </TD
 770 ></TR
 771 ></TBODY
 772 ></TABLE
 773 ><P
 774 ></P
 775 ><P
 776 ></P
 777 ><TABLE
 778 BORDER="0"
 779 ><TBODY
 780 ><TR
 781 ><TD
 782 >          <TT
 783 CLASS="FILENAME"
 784 >FAQ</TT
 785 > (doc/webserver/faq/)
 786          </TD
 787 ></TR
 788 ></TBODY
 789 ></TABLE
 790 ><P
 791 ></P
 792 ><P
 793 >          Also suggested: <TT
 794 CLASS="FILENAME"
 795 >Developer Manual</TT
 796 >
 797           (doc/webserver/developer-manual) and <TT
 798 CLASS="FILENAME"
 799 >ChangeLog</TT
 800 >
 801           (top-level directory). <TT
 802 CLASS="FILENAME"
 803 >FAQ</TT
 804 > and the manuals are
 805           HTML docs.
 806         </P
 807 ><P
 808 >         The documentation has been designed such that the manuals are linked
 809          to each other from parallel directories, and should be packaged
 810          that way. <TT
 811 CLASS="FILENAME"
 812 >privoxy-index.html</TT
 813 > can also be
 814          included and can serve as a focal point for docs and other links of
 815          interest (and possibly renamed to <TT
 816 CLASS="FILENAME"
 817 >index.html</TT
 818 >).
 819          This should be one level up from the manuals. There is a link also
 820          on this page to an HTMLized version of the man page. To avoid 404 for
 821          this, it is in Git as
 822          <TT
 823 CLASS="FILENAME"
 824 >doc/webserver/man-page/privoxy-man-page.html</TT
 825 >,
 826          and should be included along with the manuals. There is also a
 827          css stylesheets that can be included for better presentation:
 828          <TT
 829 CLASS="FILENAME"
 830 >p_doc.css</TT
 831 >. This should be in the same directory
 832          with <TT
 833 CLASS="FILENAME"
 834 >privoxy-index.html</TT
 835 >, (i.e. one level up from
 836          the manual directories).
 837         </P
 838 ></LI
 839 ><LI
 840 ><P
 841 >        <TT
 842 CLASS="FILENAME"
 843 >user.action</TT
 844 > and <TT
 845 CLASS="FILENAME"
 846 >user.filter</TT
 847 >
 848         are designed for local preferences. Make sure these do not get overwritten!
 849         <TT
 850 CLASS="FILENAME"
 851 >config</TT
 852 > should not be overwritten either. This
 853         has especially important configuration data in it.
 854         <TT
 855 CLASS="FILENAME"
 856 >trust</TT
 857 > should be left in tact as well.
 858        </P
 859 ></LI
 860 ><LI
 861 ><P
 862 >        Other configuration files (<TT
 863 CLASS="FILENAME"
 864 >default.action</TT
 865 >,
 866         <TT
 867 CLASS="FILENAME"
 868 >regression-tests.action</TT
 869 > and
 870         <TT
 871 CLASS="FILENAME"
 872 >default.filter</TT
 873 >) should be installed as the new
 874         defaults, but all previously installed configuration files should be
 875         preserved as backups. This is just good manners :-) These files are
 876         likely to change between releases and contain important new features
 877         and bug fixes.
 878        </P
 879 ></LI
 880 ><LI
 881 ><P
 882 >       Please check platform specific notes in this doc, if you haven't
 883        done <SPAN
 884 CLASS="QUOTE"
 885 >"Privoxy"</SPAN
 886 > packaging before for other platform
 887        specific issues. Conversely, please add any notes that you know
 888        are important for your platform (or contact one of the doc
 889        maintainers to do this if you can't).
 890       </P
 891 ></LI
 892 ><LI
 893 ><P
 894 >       Packagers should do a <SPAN
 895 CLASS="QUOTE"
 896 >"clean"</SPAN
 897 > install of their
 898        package after building it. So any previous installs should be
 899        removed first to ensure the integrity of the newly built package.
 900        Then run the package for a while to make sure there are no
 901        obvious problems, before uploading.
 902      </P
 903 ></LI
 904 ></UL
 905 ></DIV
 906 ><DIV
 907 CLASS="SECT3"
 908 ><H3
 909 CLASS="SECT3"
 910 ><A
 911 NAME="NEWRELEASE-TARBALL"
 912 >6.3.2. Source Tarball</A
 913 ></H3
 914 ><P
 915 >        First, <SPAN
 916 CLASS="emphasis"
 917 ><I
 918 CLASS="EMPHASIS"
 919 >make sure that you have freshly exported the right
 920         version into an empty directory</I
 921 ></SPAN
 922 >. (See "Building and releasing
 923         packages" above). Then run from that directory:
 924       </P
 925 ><TABLE
 926 BORDER="0"
 927 BGCOLOR="#E0E0E0"
 928 WIDTH="100%"
 929 ><TR
 930 ><TD
 931 ><PRE
 932 CLASS="PROGRAMLISTING"
 933 >  autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
 934 ></TD
 935 ></TR
 936 ></TABLE
 937 ><P
 938 >        Then do:
 939       </P
 940 ><TABLE
 941 BORDER="0"
 942 BGCOLOR="#E0E0E0"
 943 WIDTH="100%"
 944 ><TR
 945 ><TD
 946 ><PRE
 947 CLASS="PROGRAMLISTING"
 948 >  make tarball-dist</PRE
 949 ></TD
 950 ></TR
 951 ></TABLE
 952 ></DIV
 953 ><DIV
 954 CLASS="SECT3"
 955 ><H3
 956 CLASS="SECT3"
 957 ><A
 958 NAME="NEWRELEASE-WINDOWS"
 959 >6.3.3. Windows</A
 960 ></H3
 961 ><P
 962 >        Note that the docbook generated files might need some hand editing,
 963         so the Windows build makefile does not rebuild the docs.
 964       </P
 965 ><P
 966 >        First, <SPAN
 967 CLASS="emphasis"
 968 ><I
 969 CLASS="EMPHASIS"
 970 >make sure that you have freshly exported the right
 971         version into an empty directory</I
 972 ></SPAN
 973 >. (See "Building and releasing
 974         packages" above).
 975       </P
 976 ><P
 977 >        Check that you have the current versions of the
 978         <A
 979 HREF="https://sourceforge.net/projects/nsis/files/NSIS%203/"
 980 TARGET="_top"
 981 >                    NSIS installer</A
 982 >,
 983         <A
 984 HREF="https://ftp.pcre.org/pub/pcre/"
 985 TARGET="_top"
 986 >PCRE library</A
 987 >,
 988         <A
 989 HREF="https://tls.mbed.org/download"
 990 TARGET="_top"
 991 >MBED TLS library</A
 992 >,
 993         <A
 994 HREF="https://github.com/google/brotli/releases"
 995 TARGET="_top"
 996 >                    Brotli library</A
 997 >,
 998         and that the <SPAN
 999 CLASS="emphasis"
1000 ><I
1001 CLASS="EMPHASIS"
1002 >MAKENSIS</I
1003 ></SPAN
1004 > evar in
1005         <TT
1006 CLASS="FILENAME"
1007 >windows/GNUMakefile</TT
1008 >
1009         points to the NSIS installer program.  (See the
1010         <A
1011 HREF="../user-manual/installation.html#WINBUILD-CYGWIN"
1012 TARGET="_top"
1013 >        <SPAN
1014 CLASS="emphasis"
1015 ><I
1016 CLASS="EMPHASIS"
1017 >Building from Source / Windows</I
1018 ></SPAN
1019 ></A
1020 >
1021         section of the User Manual for details.)
1022       </P
1023 ><P
1024 >        Then you can build the package.  This is fully automated, and is
1025         controlled by <TT
1026 CLASS="FILENAME"
1027 >windows/GNUmakefile</TT
1028 >.
1029         All you need to do is:
1030       </P
1031 ><TABLE
1032 BORDER="0"
1033 BGCOLOR="#E0E0E0"
1034 WIDTH="100%"
1035 ><TR
1036 ><TD
1037 ><PRE
1038 CLASS="PROGRAMLISTING"
1039 >  cd windows
1040   make</PRE
1041 ></TD
1042 ></TR
1043 ></TABLE
1044 ><P
1045 >        Now you can manually rename <TT
1046 CLASS="FILENAME"
1047 >privoxy_setup.exe</TT
1048 > to
1049         <TT
1050 CLASS="FILENAME"
1051 >privoxy_setup_X.Y.Z.exe</TT
1052 >, and the <TT
1053 CLASS="FILENAME"
1054 >build</TT
1055 >
1056         directory to <TT
1057 CLASS="FILENAME"
1058 >privoxy_X.Y.Z</TT
1059 >.
1060         Create a .zip file of the newly renamed <TT
1061 CLASS="FILENAME"
1062 >privoxy_X.Y.Z</TT
1063 > directory,
1064         GPG sign the installer and zip file,
1065       </P
1066 ><TABLE
1067 BORDER="0"
1068 BGCOLOR="#E0E0E0"
1069 WIDTH="100%"
1070 ><TR
1071 ><TD
1072 ><PRE
1073 CLASS="PROGRAMLISTING"
1074 >  gpg --armor --detach --sign <TT
1075 CLASS="FILENAME"
1076 >privoxy_setup_X.Y.Z.exe</TT
1077 >
1078   gpg --armor --detach --sign <TT
1079 CLASS="FILENAME"
1080 >privoxy_X.Y.Z.zip</TT
1081 ></PRE
1082 ></TD
1083 ></TR
1084 ></TABLE
1085 ><P
1086 >        and upload the files to SourceForge.
1087       </P
1088 ><P
1089 >        When releasing the package on SourceForge, use the release notes
1090         and Change Log from the source tarball package.
1091       </P
1092 ></DIV
1093 ><DIV
1094 CLASS="SECT3"
1095 ><H3
1096 CLASS="SECT3"
1097 ><A
1098 NAME="NEWRELEASE-DEBIAN"
1099 >6.3.4. Debian</A
1100 ></H3
1101 ><P
1102 >       Using git-buildpackage we start with a clone of the last Debian version:
1103       </P
1104 ><TABLE
1105 BORDER="0"
1106 BGCOLOR="#E0E0E0"
1107 WIDTH="100%"
1108 ><TR
1109 ><TD
1110 ><PRE
1111 CLASS="PROGRAMLISTING"
1112 >  gbp clone https://salsa.debian.org/debian/privoxy.git
1113   cd privoxy</PRE
1114 ></TD
1115 ></TR
1116 ></TABLE
1117 ><P
1118 >       or if the repository is already there
1119       </P
1120 ><TABLE
1121 BORDER="0"
1122 BGCOLOR="#E0E0E0"
1123 WIDTH="100%"
1124 ><TR
1125 ><TD
1126 ><PRE
1127 CLASS="PROGRAMLISTING"
1128 >  cd privoxy
1129   gbp pull</PRE
1130 ></TD
1131 ></TR
1132 ></TABLE
1133 ><P
1134 >       Now import the newly released upstream tarball via debian/watch file:
1135       </P
1136 ><TABLE
1137 BORDER="0"
1138 BGCOLOR="#E0E0E0"
1139 WIDTH="100%"
1140 ><TR
1141 ><TD
1142 ><PRE
1143 CLASS="PROGRAMLISTING"
1144 >  gbp import-orig --uscan</PRE
1145 ></TD
1146 ></TR
1147 ></TABLE
1148 ><P
1149 >       Next update all Debian quilt patches to the new version:
1150       </P
1151 ><TABLE
1152 BORDER="0"
1153 BGCOLOR="#E0E0E0"
1154 WIDTH="100%"
1155 ><TR
1156 ><TD
1157 ><PRE
1158 CLASS="PROGRAMLISTING"
1159 >  while quilt push; do quilt refresh; done</PRE
1160 ></TD
1161 ></TR
1162 ></TABLE
1163 ><P
1164 >       If some patch is no longer required (because it is already merged
1165        upstream), it can be removed using
1166       </P
1167 ><TABLE
1168 BORDER="0"
1169 BGCOLOR="#E0E0E0"
1170 WIDTH="100%"
1171 ><TR
1172 ><TD
1173 ><PRE
1174 CLASS="PROGRAMLISTING"
1175 >  quilt delete XX_patchname.patch
1176   git rm debian/patches/XX_patchname.patch</PRE
1177 ></TD
1178 ></TR
1179 ></TABLE
1180 ><P
1181 >       If the patch needs modification, you can apply, edit and update it with
1182       </P
1183 ><TABLE
1184 BORDER="0"
1185 BGCOLOR="#E0E0E0"
1186 WIDTH="100%"
1187 ><TR
1188 ><TD
1189 ><PRE
1190 CLASS="PROGRAMLISTING"
1191 >  quilt push -f
1192   quilt edit some_file
1193   quilt refresh</PRE
1194 ></TD
1195 ></TR
1196 ></TABLE
1197 ><P
1198 >       until
1199       </P
1200 ><TABLE
1201 BORDER="0"
1202 BGCOLOR="#E0E0E0"
1203 WIDTH="100%"
1204 ><TR
1205 ><TD
1206 ><PRE
1207 CLASS="PROGRAMLISTING"
1208 >  while quilt push; do quilt refresh; done</PRE
1209 ></TD
1210 ></TR
1211 ></TABLE
1212 ><P
1213 >       succeeds. Then you can
1214       </P
1215 ><TABLE
1216 BORDER="0"
1217 BGCOLOR="#E0E0E0"
1218 WIDTH="100%"
1219 ><TR
1220 ><TD
1221 ><PRE
1222 CLASS="PROGRAMLISTING"
1223 >  quilt pop -a</PRE
1224 ></TD
1225 ></TR
1226 ></TABLE
1227 ><P
1228 >       Now add a new entry to the debian/changelog representing the new
1229        version:
1230       </P
1231 ><TABLE
1232 BORDER="0"
1233 BGCOLOR="#E0E0E0"
1234 WIDTH="100%"
1235 ><TR
1236 ><TD
1237 ><PRE
1238 CLASS="PROGRAMLISTING"
1239 >  dch -v 3.0.34-1</PRE
1240 ></TD
1241 ></TR
1242 ></TABLE
1243 ><P
1244 >       and describe what you did before and don't forget to git commit all
1245        changes.
1246       </P
1247 ><P
1248 >       Now you can build the package on the local machine using
1249       </P
1250 ><TABLE
1251 BORDER="0"
1252 BGCOLOR="#E0E0E0"
1253 WIDTH="100%"
1254 ><TR
1255 ><TD
1256 ><PRE
1257 CLASS="PROGRAMLISTING"
1258 >  gbp buildpackage -us -uc</PRE
1259 ></TD
1260 ></TR
1261 ></TABLE
1262 ><P
1263 >       You should check for warnings using
1264       </P
1265 ><TABLE
1266 BORDER="0"
1267 BGCOLOR="#E0E0E0"
1268 WIDTH="100%"
1269 ><TR
1270 ><TD
1271 ><PRE
1272 CLASS="PROGRAMLISTING"
1273 >  lintian -iI ../build-area/privoxy_3.0.34-1_amd64.changes</PRE
1274 ></TD
1275 ></TR
1276 ></TABLE
1277 ><P
1278 >       Maybe rebuild the package in different defined cowbuilder environments
1279        like
1280       </P
1281 ><TABLE
1282 BORDER="0"
1283 BGCOLOR="#E0E0E0"
1284 WIDTH="100%"
1285 ><TR
1286 ><TD
1287 ><PRE
1288 CLASS="PROGRAMLISTING"
1289 >  sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_3.0.34-1.dsc</PRE
1290 ></TD
1291 ></TR
1292 ></TABLE
1293 ><P
1294 >       And try to run autopackage testing suite on the result:
1295       </P
1296 ><TABLE
1297 BORDER="0"
1298 BGCOLOR="#E0E0E0"
1299 WIDTH="100%"
1300 ><TR
1301 ><TD
1302 ><PRE
1303 CLASS="PROGRAMLISTING"
1304 >  autopkgtest /var/cache/pbuilder/result/privoxy_3.0.34-1_amd64.changes -s -- schroot sid</PRE
1305 ></TD
1306 ></TR
1307 ></TABLE
1308 ><P
1309 >       Or just push the changes to salsa.debian.org, where a CI pipeline is
1310        defined for the package, that builds and tests it.
1311       </P
1312 ><P
1313 >       If everything is okay, run cowbuilder with i386 and amd64 environments
1314        for current Debian stable release and build
1315        privoxy_3.0.34-1_i386.deb and privoxy_3.0.34-1_amd64.deb.
1316        Then sign both files:
1317       </P
1318 ><TABLE
1319 BORDER="0"
1320 BGCOLOR="#E0E0E0"
1321 WIDTH="100%"
1322 ><TR
1323 ><TD
1324 ><PRE
1325 CLASS="PROGRAMLISTING"
1326 >  gpg --detach-sign --armor privoxy_3.0.34-1_i386.deb
1327   gpg --detach-sign --armor privoxy_3.0.34-1_amd64.deb</PRE
1328 ></TD
1329 ></TR
1330 ></TABLE
1331 ><P
1332 >       Create a README file containing the recent block from debian/changelog
1333        and upload the two packages, the two signatures and the README to a
1334        freshly created folder below
1335        https://sourceforge.net/projects/ijbswa/files/Debian/
1336       </P
1337 ><DIV
1338 CLASS="SECT4"
1339 ><H4
1340 CLASS="SECT4"
1341 ><A
1342 NAME="SNAPSHOT-DEBIAN"
1343 >6.3.4.1. Debian GIT Snapshot</A
1344 ></H4
1345 ><P
1346 >       For building just a git snapshot build the following workflow may be
1347        useful.  First create a build environment, for this you may have to
1348        run the following commands:
1349       </P
1350 ><TABLE
1351 BORDER="0"
1352 BGCOLOR="#E0E0E0"
1353 WIDTH="100%"
1354 ><TR
1355 ><TD
1356 ><PRE
1357 CLASS="PROGRAMLISTING"
1358 >  sudo apt install build-essential devscripts
1359   sudo apt-get build-dep privoxy</PRE
1360 ></TD
1361 ></TR
1362 ></TABLE
1363 ><P
1364 >       After this enter the checked out privoxy git tree and check that all
1365        (new) build dependencies are met:
1366       </P
1367 ><TABLE
1368 BORDER="0"
1369 BGCOLOR="#E0E0E0"
1370 WIDTH="100%"
1371 ><TR
1372 ><TD
1373 ><PRE
1374 CLASS="PROGRAMLISTING"
1375 >  dpkg-checkbuilddeps</PRE
1376 ></TD
1377 ></TR
1378 ></TABLE
1379 ><P
1380 >       If something is missing, just add it using
1381       </P
1382 ><TABLE
1383 BORDER="0"
1384 BGCOLOR="#E0E0E0"
1385 WIDTH="100%"
1386 ><TR
1387 ><TD
1388 ><PRE
1389 CLASS="PROGRAMLISTING"
1390 >  sudo apt install foobar</PRE
1391 ></TD
1392 ></TR
1393 ></TABLE
1394 ><P
1395 >       Now you may update debian/changelog, especially the version number
1396        using
1397       </P
1398 ><TABLE
1399 BORDER="0"
1400 BGCOLOR="#E0E0E0"
1401 WIDTH="100%"
1402 ><TR
1403 ><TD
1404 ><PRE
1405 CLASS="PROGRAMLISTING"
1406 >  dch</PRE
1407 ></TD
1408 ></TR
1409 ></TABLE
1410 ><P
1411 >       and finally build the package:
1412       </P
1413 ><TABLE
1414 BORDER="0"
1415 BGCOLOR="#E0E0E0"
1416 WIDTH="100%"
1417 ><TR
1418 ><TD
1419 ><PRE
1420 CLASS="PROGRAMLISTING"
1421 >  debuild -us -uc -b</PRE
1422 ></TD
1423 ></TR
1424 ></TABLE
1425 ><P
1426 >       If everything went okay, you may find the resulting Debian package in
1427        the parent directory.
1428       </P
1429 ><P
1430 >       You may want to clean up the build tree using
1431       </P
1432 ><TABLE
1433 BORDER="0"
1434 BGCOLOR="#E0E0E0"
1435 WIDTH="100%"
1436 ><TR
1437 ><TD
1438 ><PRE
1439 CLASS="PROGRAMLISTING"
1440 >  debian/rules clean</PRE
1441 ></TD
1442 ></TR
1443 ></TABLE
1444 ><P
1445 >       And maybe repair some artefacts using one or both of the following
1446        commands:
1447       </P
1448 ><TABLE
1449 BORDER="0"
1450 BGCOLOR="#E0E0E0"
1451 WIDTH="100%"
1452 ><TR
1453 ><TD
1454 ><PRE
1455 CLASS="PROGRAMLISTING"
1456 >  git reset --hard
1457   git clean -fd</PRE
1458 ></TD
1459 ></TR
1460 ></TABLE
1461 ></DIV
1462 ></DIV
1463 ><DIV
1464 CLASS="SECT3"
1465 ><H3
1466 CLASS="SECT3"
1467 ><A
1468 NAME="NEWRELEASE-MACOSX"
1469 >6.3.5. macOS / OS X</A
1470 ></H3
1471 ><P
1472 >        First, <SPAN
1473 CLASS="emphasis"
1474 ><I
1475 CLASS="EMPHASIS"
1476 >make sure that you have freshly exported the right
1477         version into an empty directory</I
1478 ></SPAN
1479 >. (See "Building and releasing
1480         packages" above).
1481       </P
1482 ><P
1483 >        The OSXPackageBuilder module generates OS X installer packages
1484         supporting all Macs running OS X 10.4 and above. Obtain it from Git as
1485         follows into a folder parallel to the exported privoxy source:
1486       </P
1487 ><TABLE
1488 BORDER="0"
1489 BGCOLOR="#E0E0E0"
1490 WIDTH="100%"
1491 ><TR
1492 ><TD
1493 ><PRE
1494 CLASS="PROGRAMLISTING"
1495 >  git clone ssh://git@git.privoxy.org:23/git/OSXPackageBuilder.git</PRE
1496 ></TD
1497 ></TR
1498 ></TABLE
1499 ><P
1500 >        The module contains complete instructions on its usage in the file
1501         <TT
1502 CLASS="FILENAME"
1503 >OS X Package Builder HOWTO.txt</TT
1504 >.
1505       </P
1506 ><P
1507 >        Once the package(s) have been generated, you can then upload them
1508         directly to the Files section of the Sourceforge project in the
1509         Macintosh (OS X) folder. Each new version release of Privoxy should
1510         have a new subfolder created in which to store its files. Please
1511         ensure that the folder contains a readme file that makes it clear
1512         which package is for which version of OS X.
1513       </P
1514 ></DIV
1515 ><DIV
1516 CLASS="SECT3"
1517 ><H3
1518 CLASS="SECT3"
1519 ><A
1520 NAME="NEWRELEASE-FREEBSD"
1521 >6.3.6. FreeBSD</A
1522 ></H3
1523 ><P
1524 >        Update the www/privoxy port and submit a diff upstream.
1525         For details see the <A
1526 HREF="https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/"
1527 TARGET="_top"
1528 >FreeBSD Porter's Handbook</A
1529 >.
1530       </P
1531 ></DIV
1532 ></DIV
1533 ><DIV
1534 CLASS="SECT2"
1535 ><H2
1536 CLASS="SECT2"
1537 ><A
1538 NAME="RELEASING"
1539 >6.4. Uploading and Releasing Your Package</A
1540 ></H2
1541 ><P
1542 >      After the package is ready, it is time to upload it
1543       and go through the release steps. The upload
1544       is done at
1545       <A
1546 HREF="https://sourceforge.net/projects/ijbswa/upload/"
1547 TARGET="_top"
1548 >SourceForge</A
1549 >
1550       after logging in.
1551     </P
1552 ><P
1553 >     Now just follow the prompts. Be sure to add any appropriate Release
1554      notes. You should see your freshly uploaded packages in
1555      <SPAN
1556 CLASS="QUOTE"
1557 >"Step 2. Add Files To This Release"</SPAN
1558 >. Check the
1559      appropriate box(es). Remember at each step to hit the
1560      <SPAN
1561 CLASS="QUOTE"
1562 >"Refresh/Submit"</SPAN
1563 > buttons! You should now see your
1564      file(s) listed in Step 3. Fill out the forms with the appropriate
1565      information for your platform, being sure to hit <SPAN
1566 CLASS="QUOTE"
1567 >"Update"</SPAN
1568 >
1569      for each file. If anyone is monitoring your platform, check the
1570      <SPAN
1571 CLASS="QUOTE"
1572 >"email"</SPAN
1573 > box at the very bottom to notify them of
1574      the new package. This should do it!
1575     </P
1576 ><P
1577 >     If you have made errors, or need to make changes, you can go through
1578      essentially the same steps, but select <TT
1579 CLASS="LITERAL"
1580 >Edit Release</TT
1581 >,
1582      instead of <TT
1583 CLASS="LITERAL"
1584 >Add Release</TT
1585 >.
1586     </P
1587 ></DIV
1588 ><DIV
1589 CLASS="SECT2"
1590 ><H2
1591 CLASS="SECT2"
1592 ><A
1593 NAME="AFTERRELEASE"
1594 >6.5. After the Release</A
1595 ></H2
1596 ><P
1597 >      When all (or: most of the) packages have been uploaded and made available,
1598       send an email to the
1599       <A
1600 HREF="mailto:privoxy-announce@lists.privoxy.org"
1601 TARGET="_top"
1602 >announce mailing
1603       list</A
1604 >, Subject: "Announcing Privoxy X.Y.Z $CODE_STATUS". Be sure to
1605       include the
1606       <A
1607 HREF="https://sourceforge.net/projects/ijbswa/files/"
1608 TARGET="_top"
1609 >      download location</A
1610 >, the release notes and the Changelog. Also, post an
1611       updated News item on the project page Sourceforge, and update the Home
1612       page and docs linked from the Home page (see below). Other news sites
1613       and release oriented sites, such as Freshmeat, should also be notified.
1614      </P
1615 ><P
1616 >      Then update the source code for the next version to be released:
1617      </P
1618 ><P
1619 ></P
1620 ><UL
1621 ><LI
1622 ><P
1623 >        Increment the version number and change the code status to "UNRELEASED"
1624         in <TT
1625 CLASS="FILENAME"
1626 >configure.in</TT
1627 >
1628        </P
1629 ></LI
1630 ><LI
1631 ><P
1632 >        Rebuild configure (<SPAN
1633 CLASS="QUOTE"
1634 >"<B
1635 CLASS="COMMAND"
1636 >autoheader &#38;&#38; autoconf</B
1637 >"</SPAN
1638 >)
1639         and GNUMakefile (<SPAN
1640 CLASS="QUOTE"
1641 >"<B
1642 CLASS="COMMAND"
1643 >./configure</B
1644 >"</SPAN
1645 >)
1646        </P
1647 ></LI
1648 ><LI
1649 ><P
1650 >        <SPAN
1651 CLASS="QUOTE"
1652 >"<B
1653 CLASS="COMMAND"
1654 >make dok-release</B
1655 >"</SPAN
1656 > to update the sgml documentation source files.
1657        </P
1658 ></LI
1659 ><LI
1660 ><P
1661 >        Commit all your changes.
1662        </P
1663 ></LI
1664 ></UL
1665 ></DIV
1666 ></DIV
1667 ><DIV
1668 CLASS="NAVFOOTER"
1669 ><HR
1670 ALIGN="LEFT"
1671 WIDTH="100%"><TABLE
1672 SUMMARY="Footer navigation table"
1673 WIDTH="100%"
1674 BORDER="0"
1675 CELLPADDING="0"
1676 CELLSPACING="0"
1677 ><TR
1678 ><TD
1679 WIDTH="33%"
1680 ALIGN="left"
1681 VALIGN="top"
1682 ><A
1683 HREF="testing.html"
1684 ACCESSKEY="P"
1685 >Prev</A
1686 ></TD
1687 ><TD
1688 WIDTH="34%"
1689 ALIGN="center"
1690 VALIGN="top"
1691 ><A
1692 HREF="index.html"
1693 ACCESSKEY="H"
1694 >Home</A
1695 ></TD
1696 ><TD
1697 WIDTH="33%"
1698 ALIGN="right"
1699 VALIGN="top"
1700 ><A
1701 HREF="webserver-update.html"
1702 ACCESSKEY="N"
1703 >Next</A
1704 ></TD
1705 ></TR
1706 ><TR
1707 ><TD
1708 WIDTH="33%"
1709 ALIGN="left"
1710 VALIGN="top"
1711 >Testing Guidelines</TD
1712 ><TD
1713 WIDTH="34%"
1714 ALIGN="center"
1715 VALIGN="top"
1716 >&nbsp;</TD
1717 ><TD
1718 WIDTH="33%"
1719 ALIGN="right"
1720 VALIGN="top"
1721 >Update the Webserver</TD
1722 ></TR
1723 ></TABLE
1724 ></DIV
1725 ></BODY
1726 ></HTML
1727 >