doc/webserver/developer-manual/newrelease.html

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