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