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