doc/webserver/developer-manual/newrelease.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   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.7"><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 >6. Releasing a New Version</A
  78 ></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 >6.1. Version numbers</A
 115 ></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 <VAR
 178 CLASS="LITERAL"
 179 >0.0.0</VAR
 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               <VAR
 191 CLASS="LITERAL"
 192 >3.0.1 -&#62; 0.0.0 -&#62; 3.0.2</VAR
 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      <VAR
 205 CLASS="LITERAL"
 206 >3.0</VAR
 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 <VAR
 236 CLASS="LITERAL"
 237 >v_3_0_branch</VAR
 238 > at the moment).
 239     </P
 240 ></DIV
 241 ><DIV
 242 CLASS="SECT2"
 243 ><H2
 244 CLASS="SECT2"
 245 ><A
 246 NAME="BEFORERELEASE"
 247 >6.2. Before the Release: Freeze</A
 248 ></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          <VAR
 347 CLASS="LITERAL"
 348 >http://privoxy.org/$(VERSION)/user-manual/</VAR
 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 >6.3. Building and Releasing the Packages</A
 433 ></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 >6.3.1. Note on Privoxy Packaging</A
 498 ></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 >6.3.2. Source Tarball</A
 746 ></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 >6.3.3. SuSE, Conectiva or Red Hat RPM</A
 826 ></H3
 827 ><P
 828 >        In following text, replace <VAR
 829 CLASS="REPLACEABLE"
 830 >dist</VAR
 831 >
 832         with either <SPAN
 833 CLASS="QUOTE"
 834 >"rh"</SPAN
 835 > for Red Hat or <SPAN
 836 CLASS="QUOTE"
 837 >"suse"</SPAN
 838 > for SuSE.
 839         </P
 840 ><P
 841 >       First, <SPAN
 842 CLASS="emphasis"
 843 ><I
 844 CLASS="EMPHASIS"
 845 >make sure that you have freshly exported the right
 846         version into an empty directory</I
 847 ></SPAN
 848 >. (See "Building and releasing
 849         packages" above).
 850         </P
 851 ><P
 852 >        As the only exception to not changing anything after export from CVS,
 853         now examine the file <TT
 854 CLASS="FILENAME"
 855 >privoxy-</TT
 856 ><VAR
 857 CLASS="REPLACEABLE"
 858 >dist</VAR
 859 ><TT
 860 CLASS="FILENAME"
 861 >.spec</TT
 862 >
 863         and make sure that the version information and the RPM release number are
 864         correct. The RPM release numbers for each version start at one. Hence it must
 865         be reset to one if this is the first RPM for
 866         <VAR
 867 CLASS="REPLACEABLE"
 868 >dist</VAR
 869 > which is built from version
 870         X.Y.Z. Check the
 871         <A
 872 HREF="http://sourceforge.net/project/showfiles.php?group_id=11118"
 873 TARGET="_top"
 874 >file
 875         list</A
 876 > if unsure. Else, it must be set to the highest already available RPM
 877         release number for that version plus one.
 878         </P
 879 ><P
 880 >        Then run:
 881         </P
 882 ><P
 883 >       <TABLE
 884 BORDER="0"
 885 BGCOLOR="#E0E0E0"
 886 WIDTH="100%"
 887 ><TR
 888 ><TD
 889 ><PRE
 890 CLASS="PROGRAMLISTING"
 891 >  cd current
 892   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
 893 ></TD
 894 ></TR
 895 ></TABLE
 896 >
 897         </P
 898 ><P
 899 >       Then do
 900         </P
 901 ><P
 902 >       <TABLE
 903 BORDER="0"
 904 BGCOLOR="#E0E0E0"
 905 WIDTH="100%"
 906 ><TR
 907 ><TD
 908 ><PRE
 909 CLASS="PROGRAMLISTING"
 910 >  make <VAR
 911 CLASS="REPLACEABLE"
 912 >dist</VAR
 913 >-dist</PRE
 914 ></TD
 915 ></TR
 916 ></TABLE
 917 >
 918         </P
 919 ><P
 920 >       To upload the package to Sourceforge, simply issue
 921         </P
 922 ><P
 923 >       <TABLE
 924 BORDER="0"
 925 BGCOLOR="#E0E0E0"
 926 WIDTH="100%"
 927 ><TR
 928 ><TD
 929 ><PRE
 930 CLASS="PROGRAMLISTING"
 931 >  make <VAR
 932 CLASS="REPLACEABLE"
 933 >dist</VAR
 934 >-upload <VAR
 935 CLASS="REPLACEABLE"
 936 >rpm_packagerev</VAR
 937 ></PRE
 938 ></TD
 939 ></TR
 940 ></TABLE
 941 >
 942         </P
 943 ><P
 944 >        where <VAR
 945 CLASS="REPLACEABLE"
 946 >rpm_packagerev</VAR
 947 > is the
 948         RPM release number as determined above.
 949         Go to the displayed URL and release the file publicly on Sourceforge.
 950         Use the release notes and change log from the source tarball package.
 951       </P
 952 ></DIV
 953 ><DIV
 954 CLASS="SECT3"
 955 ><H3
 956 CLASS="SECT3"
 957 ><A
 958 NAME="NEWRELEASE-OS2"
 959 >6.3.4. OS/2</A
 960 ></H3
 961 ><P
 962 >       First, <SPAN
 963 CLASS="emphasis"
 964 ><I
 965 CLASS="EMPHASIS"
 966 >make sure that you have freshly exported the right
 967         version into an empty directory</I
 968 ></SPAN
 969 >. (See "Building and releasing
 970         packages" above). Then get the OS/2 Setup module:
 971         </P
 972 ><P
 973 >       <TABLE
 974 BORDER="0"
 975 BGCOLOR="#E0E0E0"
 976 WIDTH="100%"
 977 ><TR
 978 ><TD
 979 ><PRE
 980 CLASS="PROGRAMLISTING"
 981 >  cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup</PRE
 982 ></TD
 983 ></TR
 984 ></TABLE
 985 >
 986         </P
 987 ><P
 988 >       You will need a mix of development tools.
 989         The main compilation takes place with IBM Visual Age C++.
 990         Some ancillary work takes place with GNU tools, available from
 991         various sources like hobbes.nmsu.edu.
 992         Specificially, you will need <TT
 993 CLASS="FILENAME"
 994 >autoheader</TT
 995 >,
 996         <TT
 997 CLASS="FILENAME"
 998 >autoconf</TT
 999 > and <TT
1000 CLASS="FILENAME"
1001 >sh</TT
1002 > tools.
1003         The packaging takes place with WarpIN, available from various sources, including
1004         its home page: <A
1005 HREF="http://www.xworkplace.org/"
1006 TARGET="_top"
1007 >xworkplace</A
1008 >.
1009         </P
1010 ><P
1011 >       Change directory to the <TT
1012 CLASS="FILENAME"
1013 >os2setup</TT
1014 > directory.
1015         Edit the os2build.cmd file to set the final executable filename.
1016         For example,
1017         </P
1018 ><P
1019 >       <TABLE
1020 BORDER="0"
1021 BGCOLOR="#E0E0E0"
1022 WIDTH="100%"
1023 ><TR
1024 ><TD
1025 ><PRE
1026 CLASS="PROGRAMLISTING"
1027 >  installExeName='privoxyos2_setup_X.Y.Z.exe'</PRE
1028 ></TD
1029 ></TR
1030 ></TABLE
1031 >
1032         </P
1033 ><P
1034 >       Next, edit the <TT
1035 CLASS="FILENAME"
1036 >IJB.wis</TT
1037 > file so the release number matches
1038         in the <TT
1039 CLASS="FILENAME"
1040 >PACKAGEID</TT
1041 > section:
1042         </P
1043 ><P
1044 >       <TABLE
1045 BORDER="0"
1046 BGCOLOR="#E0E0E0"
1047 WIDTH="100%"
1048 ><TR
1049 ><TD
1050 ><PRE
1051 CLASS="PROGRAMLISTING"
1052 >  PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"</PRE
1053 ></TD
1054 ></TR
1055 ></TABLE
1056 >
1057         </P
1058 ><P
1059 >       You're now ready to build.  Run:
1060         </P
1061 ><P
1062 >       <TABLE
1063 BORDER="0"
1064 BGCOLOR="#E0E0E0"
1065 WIDTH="100%"
1066 ><TR
1067 ><TD
1068 ><PRE
1069 CLASS="PROGRAMLISTING"
1070 >  os2build</PRE
1071 ></TD
1072 ></TR
1073 ></TABLE
1074 >
1075         </P
1076 ><P
1077 >         You will find the  WarpIN-installable executable in the
1078         <TT
1079 CLASS="FILENAME"
1080 >./files</TT
1081 > directory. Upload this anonymously to
1082          <TT
1083 CLASS="FILENAME"
1084 >uploads.sourceforge.net/incoming</TT
1085 >, create a release
1086          for it, and you're done. Use the release notes and Change Log from the
1087          source tarball package.
1088         </P
1089 ></DIV
1090 ><DIV
1091 CLASS="SECT3"
1092 ><H3
1093 CLASS="SECT3"
1094 ><A
1095 NAME="NEWRELEASE-SOLARIS"
1096 >6.3.5. Solaris</A
1097 ></H3
1098 ><P
1099 >       Login to Sourceforge's compilefarm via ssh:
1100         </P
1101 ><P
1102 >       <TABLE
1103 BORDER="0"
1104 BGCOLOR="#E0E0E0"
1105 WIDTH="100%"
1106 ><TR
1107 ><TD
1108 ><PRE
1109 CLASS="PROGRAMLISTING"
1110 >  ssh cf.sourceforge.net</PRE
1111 ></TD
1112 ></TR
1113 ></TABLE
1114 >
1115         </P
1116 ><P
1117 >       Choose the right operating system (not the Debian one).
1118         When logged in, <SPAN
1119 CLASS="emphasis"
1120 ><I
1121 CLASS="EMPHASIS"
1122 >make sure that you have freshly exported the right
1123         version into an empty directory</I
1124 ></SPAN
1125 >. (See "Building and releasing
1126         packages" above). Then run:
1127         </P
1128 ><P
1129 >       <TABLE
1130 BORDER="0"
1131 BGCOLOR="#E0E0E0"
1132 WIDTH="100%"
1133 ><TR
1134 ><TD
1135 ><PRE
1136 CLASS="PROGRAMLISTING"
1137 >  cd current
1138   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
1139 ></TD
1140 ></TR
1141 ></TABLE
1142 >
1143         </P
1144 ><P
1145 >       Then run
1146         </P
1147 ><P
1148 >       <TABLE
1149 BORDER="0"
1150 BGCOLOR="#E0E0E0"
1151 WIDTH="100%"
1152 ><TR
1153 ><TD
1154 ><PRE
1155 CLASS="PROGRAMLISTING"
1156 >  gmake solaris-dist</PRE
1157 ></TD
1158 ></TR
1159 ></TABLE
1160 >
1161         </P
1162 ><P
1163 >       which creates a gzip'ed tar archive. Sadly, you cannot use <B
1164 CLASS="COMMAND"
1165 >make
1166         solaris-upload</B
1167 > on the Sourceforge machine (no ncftpput). You now have
1168         to manually upload the archive to Sourceforge's ftp server and release
1169         the file publicly. Use the release notes and Change Log from the
1170         source tarball package.
1171         </P
1172 ></DIV
1173 ><DIV
1174 CLASS="SECT3"
1175 ><H3
1176 CLASS="SECT3"
1177 ><A
1178 NAME="NEWRELEASE-WINDOWS"
1179 >6.3.6. Windows</A
1180 ></H3
1181 ><P
1182 >        You should ensure you have the latest version of Cygwin (from
1183         <A
1184 HREF="http://www.cygwin.com/"
1185 TARGET="_top"
1186 >http://www.cygwin.com/</A
1187 >).
1188         Run the following commands from within a Cygwin bash shell.
1189       </P
1190 ><P
1191 >       First, <SPAN
1192 CLASS="emphasis"
1193 ><I
1194 CLASS="EMPHASIS"
1195 >make sure that you have freshly exported the right
1196         version into an empty directory</I
1197 ></SPAN
1198 >. (See "Building and releasing
1199         packages" above). Then get the Windows setup module:
1200       </P
1201 ><P
1202 >      <TABLE
1203 BORDER="0"
1204 BGCOLOR="#E0E0E0"
1205 WIDTH="100%"
1206 ><TR
1207 ><TD
1208 ><PRE
1209 CLASS="PROGRAMLISTING"
1210 >  cvs -z3  -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup</PRE
1211 ></TD
1212 ></TR
1213 ></TABLE
1214 >
1215       </P
1216 ><P
1217 >        Then you can build the package.  This is fully automated, and is
1218         controlled by <TT
1219 CLASS="FILENAME"
1220 >winsetup/GNUmakefile</TT
1221 >.
1222         All you need to do is:
1223       </P
1224 ><P
1225 >      <TABLE
1226 BORDER="0"
1227 BGCOLOR="#E0E0E0"
1228 WIDTH="100%"
1229 ><TR
1230 ><TD
1231 ><PRE
1232 CLASS="PROGRAMLISTING"
1233 >  cd winsetup
1234   make</PRE
1235 ></TD
1236 ></TR
1237 ></TABLE
1238 >
1239       </P
1240 ><P
1241 >        Now you can manually rename <TT
1242 CLASS="FILENAME"
1243 >privoxy_setup.exe</TT
1244 > to
1245         <TT
1246 CLASS="FILENAME"
1247 >privoxy_setup_X_Y_Z.exe</TT
1248 >, and upload it to
1249         SourceForge. When releasing the package on SourceForge, use the release notes
1250         and Change Log from the source tarball package.
1251       </P
1252 ></DIV
1253 ><DIV
1254 CLASS="SECT3"
1255 ><H3
1256 CLASS="SECT3"
1257 ><A
1258 NAME="NEWRELEASE-DEBIAN"
1259 >6.3.7. Debian</A
1260 ></H3
1261 ><P
1262 >        First, <SPAN
1263 CLASS="emphasis"
1264 ><I
1265 CLASS="EMPHASIS"
1266 >make sure that you have freshly exported the
1267         right version into an empty directory</I
1268 ></SPAN
1269 >. (See
1270         "Building and releasing packages" above).  Then add a log
1271         entry to <TT
1272 CLASS="FILENAME"
1273 >debian/changelog</TT
1274 >, if it is not
1275         already there, for example by running:
1276       </P
1277 ><P
1278 >        <TABLE
1279 BORDER="0"
1280 BGCOLOR="#E0E0E0"
1281 WIDTH="100%"
1282 ><TR
1283 ><TD
1284 ><PRE
1285 CLASS="PROGRAMLISTING"
1286 >  debchange -v 3.0.3-stable-1 "New upstream version"</PRE
1287 ></TD
1288 ></TR
1289 ></TABLE
1290 >
1291       </P
1292 ><P
1293 >        Then, run:
1294       </P
1295 ><P
1296 >        <TABLE
1297 BORDER="0"
1298 BGCOLOR="#E0E0E0"
1299 WIDTH="100%"
1300 ><TR
1301 ><TD
1302 ><PRE
1303 CLASS="PROGRAMLISTING"
1304 >  dpkg-buildpackage -rfakeroot -us -uc -b</PRE
1305 ></TD
1306 ></TR
1307 ></TABLE
1308 >
1309       </P
1310 ><P
1311 >        This will create
1312         <TT
1313 CLASS="FILENAME"
1314 >../privoxy_3.0.3-stable-1_i386.deb</TT
1315 >
1316         which can be uploaded.  To upload the package to Sourceforge, simply
1317         issue
1318       </P
1319 ><P
1320 >        <TABLE
1321 BORDER="0"
1322 BGCOLOR="#E0E0E0"
1323 WIDTH="100%"
1324 ><TR
1325 ><TD
1326 ><PRE
1327 CLASS="PROGRAMLISTING"
1328 >  make debian-upload</PRE
1329 ></TD
1330 ></TR
1331 ></TABLE
1332 >
1333       </P
1334 ></DIV
1335 ><DIV
1336 CLASS="SECT3"
1337 ><H3
1338 CLASS="SECT3"
1339 ><A
1340 NAME="NEWRELEASE-MACOSX"
1341 >6.3.8. Mac OSX</A
1342 ></H3
1343 ><P
1344 >       First, <SPAN
1345 CLASS="emphasis"
1346 ><I
1347 CLASS="EMPHASIS"
1348 >make sure that you have freshly exported the right
1349         version into an empty directory</I
1350 ></SPAN
1351 >. (See "Building and releasing
1352         packages" above). Then get the Mac OSX setup module:
1353         </P
1354 ><P
1355 >       <TABLE
1356 BORDER="0"
1357 BGCOLOR="#E0E0E0"
1358 WIDTH="100%"
1359 ><TR
1360 ><TD
1361 ><PRE
1362 CLASS="PROGRAMLISTING"
1363 >  cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup</PRE
1364 ></TD
1365 ></TR
1366 ></TABLE
1367 >
1368         </P
1369 ><P
1370 >       Then run:
1371         </P
1372 ><P
1373 >       <TABLE
1374 BORDER="0"
1375 BGCOLOR="#E0E0E0"
1376 WIDTH="100%"
1377 ><TR
1378 ><TD
1379 ><PRE
1380 CLASS="PROGRAMLISTING"
1381 >  cd osxsetup
1382   build</PRE
1383 ></TD
1384 ></TR
1385 ></TABLE
1386 >
1387         </P
1388 ><P
1389 >       This will run <TT
1390 CLASS="FILENAME"
1391 >autoheader</TT
1392 >, <TT
1393 CLASS="FILENAME"
1394 >autoconf</TT
1395 > and
1396         <TT
1397 CLASS="FILENAME"
1398 >configure</TT
1399 > as well as <TT
1400 CLASS="FILENAME"
1401 >make</TT
1402 >.
1403         Finally, it will copy over the necessary files to the ./osxsetup/files directory
1404         for further processing by <TT
1405 CLASS="FILENAME"
1406 >PackageMaker</TT
1407 >.
1408         </P
1409 ><P
1410 >       Bring up PackageMaker with the PrivoxyPackage.pmsp definition file, modify the package
1411         name to match the release, and hit the "Create package" button.
1412         If you specify ./Privoxy.pkg as the output package name, you can then create
1413         the distributable zip file with the command:
1414         </P
1415 ><P
1416 >       <TABLE
1417 BORDER="0"
1418 BGCOLOR="#E0E0E0"
1419 WIDTH="100%"
1420 ><TR
1421 ><TD
1422 ><PRE
1423 CLASS="PROGRAMLISTING"
1424 >  zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg</PRE
1425 ></TD
1426 ></TR
1427 ></TABLE
1428 >
1429         </P
1430 ><P
1431 >       You can then upload <TT
1432 CLASS="FILENAME"
1433 >privoxyosx_setup_x.y.z.zip</TT
1434 > anonymously to
1435         <TT
1436 CLASS="FILENAME"
1437 >uploads.sourceforge.net/incoming</TT
1438 >,
1439         create a release for it, and you're done. Use the release notes
1440         and Change Log from the source tarball package.
1441         </P
1442 ></DIV
1443 ><DIV
1444 CLASS="SECT3"
1445 ><H3
1446 CLASS="SECT3"
1447 ><A
1448 NAME="NEWRELEASE-FREEBSD"
1449 >6.3.9. FreeBSD</A
1450 ></H3
1451 ><P
1452 >       Login to Sourceforge's compile-farm via ssh:
1453         </P
1454 ><P
1455 >       <TABLE
1456 BORDER="0"
1457 BGCOLOR="#E0E0E0"
1458 WIDTH="100%"
1459 ><TR
1460 ><TD
1461 ><PRE
1462 CLASS="PROGRAMLISTING"
1463 >  ssh cf.sourceforge.net</PRE
1464 ></TD
1465 ></TR
1466 ></TABLE
1467 >
1468         </P
1469 ><P
1470 >       Choose the right operating system.
1471         When logged in, <SPAN
1472 CLASS="emphasis"
1473 ><I
1474 CLASS="EMPHASIS"
1475 >make sure that you have freshly exported the right
1476         version into an empty directory</I
1477 ></SPAN
1478 >. (See "Building and releasing
1479         packages" above). Then run:
1480         </P
1481 ><P
1482 >       <TABLE
1483 BORDER="0"
1484 BGCOLOR="#E0E0E0"
1485 WIDTH="100%"
1486 ><TR
1487 ><TD
1488 ><PRE
1489 CLASS="PROGRAMLISTING"
1490 >  cd current
1491   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
1492 ></TD
1493 ></TR
1494 ></TABLE
1495 >
1496         </P
1497 ><P
1498 >       Then run:
1499         </P
1500 ><P
1501 >       <TABLE
1502 BORDER="0"
1503 BGCOLOR="#E0E0E0"
1504 WIDTH="100%"
1505 ><TR
1506 ><TD
1507 ><PRE
1508 CLASS="PROGRAMLISTING"
1509 >  gmake freebsd-dist</PRE
1510 ></TD
1511 ></TR
1512 ></TABLE
1513 >
1514         </P
1515 ><P
1516 >       which creates a gzip'ed tar archive. Sadly, you cannot use <B
1517 CLASS="COMMAND"
1518 >make
1519         freebsd-upload</B
1520 > on the Sourceforge machine (no ncftpput). You now have
1521         to manually upload the archive to Sourceforge's ftp server and release
1522         the file publicly. Use the release notes and Change Log from the
1523         source tarball package.
1524         </P
1525 ></DIV
1526 ><DIV
1527 CLASS="SECT3"
1528 ><H3
1529 CLASS="SECT3"
1530 ><A
1531 NAME="NEWRELEASE-HPUX"
1532 >6.3.10. HP-UX 11</A
1533 ></H3
1534 ><P
1535 >       First, <SPAN
1536 CLASS="emphasis"
1537 ><I
1538 CLASS="EMPHASIS"
1539 >make sure that you have freshly exported the right
1540         version into an empty directory</I
1541 ></SPAN
1542 >. (See "Building and releasing
1543         packages" above). Then run:
1544         </P
1545 ><P
1546 >       <TABLE
1547 BORDER="0"
1548 BGCOLOR="#E0E0E0"
1549 WIDTH="100%"
1550 ><TR
1551 ><TD
1552 ><PRE
1553 CLASS="PROGRAMLISTING"
1554 >  cd current
1555   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
1556 ></TD
1557 ></TR
1558 ></TABLE
1559 >
1560         </P
1561 ><P
1562 >       Then do FIXME.
1563         </P
1564 ></DIV
1565 ><DIV
1566 CLASS="SECT3"
1567 ><H3
1568 CLASS="SECT3"
1569 ><A
1570 NAME="NEWRELEASE-AMIGA"
1571 >6.3.11. Amiga OS</A
1572 ></H3
1573 ><P
1574 >       First, <SPAN
1575 CLASS="emphasis"
1576 ><I
1577 CLASS="EMPHASIS"
1578 >make sure that you have freshly exported the right
1579         version into an empty directory</I
1580 ></SPAN
1581 >. (See "Building and releasing
1582         packages" above). Then run:
1583         </P
1584 ><P
1585 >       <TABLE
1586 BORDER="0"
1587 BGCOLOR="#E0E0E0"
1588 WIDTH="100%"
1589 ><TR
1590 ><TD
1591 ><PRE
1592 CLASS="PROGRAMLISTING"
1593 >  cd current
1594   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
1595 ></TD
1596 ></TR
1597 ></TABLE
1598 >
1599         </P
1600 ><P
1601 >       Then do FIXME.
1602         </P
1603 ></DIV
1604 ><DIV
1605 CLASS="SECT3"
1606 ><H3
1607 CLASS="SECT3"
1608 ><A
1609 NAME="NEWRELEASE-AIX"
1610 >6.3.12. AIX</A
1611 ></H3
1612 ><P
1613 >       Login to Sourceforge's compilefarm via ssh:
1614         </P
1615 ><P
1616 >       <TABLE
1617 BORDER="0"
1618 BGCOLOR="#E0E0E0"
1619 WIDTH="100%"
1620 ><TR
1621 ><TD
1622 ><PRE
1623 CLASS="PROGRAMLISTING"
1624 >  ssh cf.sourceforge.net</PRE
1625 ></TD
1626 ></TR
1627 ></TABLE
1628 >
1629         </P
1630 ><P
1631 >       Choose the right operating system.
1632         When logged in, <SPAN
1633 CLASS="emphasis"
1634 ><I
1635 CLASS="EMPHASIS"
1636 >make sure that you have freshly exported the right
1637         version into an empty directory</I
1638 ></SPAN
1639 >. (See "Building and releasing
1640         packages" above). Then run:
1641         </P
1642 ><P
1643 >       <TABLE
1644 BORDER="0"
1645 BGCOLOR="#E0E0E0"
1646 WIDTH="100%"
1647 ><TR
1648 ><TD
1649 ><PRE
1650 CLASS="PROGRAMLISTING"
1651 >  cd current
1652   autoheader &#38;&#38; autoconf &#38;&#38; ./configure</PRE
1653 ></TD
1654 ></TR
1655 ></TABLE
1656 >
1657         </P
1658 ><P
1659 >       Then run:
1660         </P
1661 ><P
1662 >       <TABLE
1663 BORDER="0"
1664 BGCOLOR="#E0E0E0"
1665 WIDTH="100%"
1666 ><TR
1667 ><TD
1668 ><PRE
1669 CLASS="PROGRAMLISTING"
1670 >  make aix-dist</PRE
1671 ></TD
1672 ></TR
1673 ></TABLE
1674 >
1675         </P
1676 ><P
1677 >       which creates a gzip'ed tar archive. Sadly, you cannot use <B
1678 CLASS="COMMAND"
1679 >make
1680         aix-upload</B
1681 > on the Sourceforge machine (no ncftpput). You now have
1682         to manually upload the archive to Sourceforge's ftp server and release
1683         the file publicly. Use the release notes and Change Log from the
1684         source tarball package.
1685         </P
1686 ></DIV
1687 ></DIV
1688 ><DIV
1689 CLASS="SECT2"
1690 ><H2
1691 CLASS="SECT2"
1692 ><A
1693 NAME="RELEASING"
1694 >6.4. Uploading and Releasing Your Package</A
1695 ></H2
1696 ><P
1697 >      After the package is ready, it is time to upload it
1698       to SourceForge, and go through the release steps. The upload
1699       is done via FTP:
1700     </P
1701 ><P
1702 >      <P
1703 ></P
1704 ><UL
1705 ><LI
1706 ><P
1707 >          Upload to: <A
1708 HREF="ftp://upload.sourceforge.net/incoming"
1709 TARGET="_top"
1710 >ftp://upload.sourceforge.net/incoming</A
1711 >
1712         </P
1713 ></LI
1714 ><LI
1715 ><P
1716 >         user: <VAR
1717 CLASS="LITERAL"
1718 >anonymous</VAR
1719 >
1720        </P
1721 ></LI
1722 ><LI
1723 ><P
1724 >         password: <VAR
1725 CLASS="LITERAL"
1726 >ijbswa-developers@lists.sourceforge.net</VAR
1727 >
1728        </P
1729 ></LI
1730 ></UL
1731 >
1732     </P
1733 ><P
1734 >     Or use the <B
1735 CLASS="COMMAND"
1736 >make</B
1737 > targets as described above.
1738     </P
1739 ><P
1740 >     Once this done go to <A
1741 HREF="http://sourceforge.net/project/admin/editpackages.php?group_id=11118"
1742 TARGET="_top"
1743 >http://sourceforge.net/project/admin/editpackages.php?group_id=11118</A
1744 >,
1745      making sure you are logged in. Find your target platform in the
1746      second column, and click <VAR
1747 CLASS="LITERAL"
1748 >Add Release</VAR
1749 >. You will
1750      then need to create a new release for your package, using the format
1751      of <VAR
1752 CLASS="LITERAL"
1753 >$VERSION ($CODE_STATUS)</VAR
1754 >, e.g. <SPAN
1755 CLASS="emphasis"
1756 ><I
1757 CLASS="EMPHASIS"
1758 >3.0.3
1759      (beta)</I
1760 ></SPAN
1761 >.
1762     </P
1763 ><P
1764 >     Now just follow the prompts. Be sure to add any appropriate Release
1765      notes. You should see your freshly uploaded packages in
1766      <SPAN
1767 CLASS="QUOTE"
1768 >"Step 2. Add Files To This Release"</SPAN
1769 >. Check the
1770      appropriate box(es). Remember at each step to hit the
1771      <SPAN
1772 CLASS="QUOTE"
1773 >"Refresh/Submit"</SPAN
1774 > buttons! You should now see your
1775      file(s) listed in Step 3. Fill out the forms with the appropriate
1776      information for your platform, being sure to hit <SPAN
1777 CLASS="QUOTE"
1778 >"Update"</SPAN
1779 >
1780      for each file. If anyone is monitoring your platform, check the
1781      <SPAN
1782 CLASS="QUOTE"
1783 >"email"</SPAN
1784 > box at the very bottom to notify them of
1785      the new package. This should do it!
1786     </P
1787 ><P
1788 >     If you have made errors, or need to make changes, you can go through
1789      essentially the same steps, but select <VAR
1790 CLASS="LITERAL"
1791 >Edit Release</VAR
1792 >,
1793      instead of <VAR
1794 CLASS="LITERAL"
1795 >Add Release</VAR
1796 >.
1797     </P
1798 ></DIV
1799 ><DIV
1800 CLASS="SECT2"
1801 ><H2
1802 CLASS="SECT2"
1803 ><A
1804 NAME="AFTERRELEASE"
1805 >6.5. After the Release</A
1806 ></H2
1807 ><P
1808 >      When all (or: most of the) packages have been uploaded and made available,
1809       send an email to the <A
1810 HREF="mailto:ijbswa-announce@lists.sourceforge.net"
1811 TARGET="_top"
1812 >announce
1813       mailing list</A
1814 >, Subject: "Version X.Y.Z available for download". Be sure to
1815       include the
1816       <A
1817 HREF="http://sourceforge.net/project/showfiles.php?group_id=11118"
1818 TARGET="_top"
1819 >download
1820       location</A
1821 >, the release notes and the Changelog. Also, post an
1822       updated News item on the project page Sourceforge, and update the Home
1823       page and docs linked from the Home page (see below).
1824      </P
1825 ></DIV
1826 ></DIV
1827 ><DIV
1828 CLASS="NAVFOOTER"
1829 ><HR
1830 ALIGN="LEFT"
1831 WIDTH="100%"><TABLE
1832 SUMMARY="Footer navigation table"
1833 WIDTH="100%"
1834 BORDER="0"
1835 CELLPADDING="0"
1836 CELLSPACING="0"
1837 ><TR
1838 ><TD
1839 WIDTH="33%"
1840 ALIGN="left"
1841 VALIGN="top"
1842 ><A
1843 HREF="testing.html"
1844 ACCESSKEY="P"
1845 >Prev</A
1846 ></TD
1847 ><TD
1848 WIDTH="34%"
1849 ALIGN="center"
1850 VALIGN="top"
1851 ><A
1852 HREF="index.html"
1853 ACCESSKEY="H"
1854 >Home</A
1855 ></TD
1856 ><TD
1857 WIDTH="33%"
1858 ALIGN="right"
1859 VALIGN="top"
1860 ><A
1861 HREF="webserver-update.html"
1862 ACCESSKEY="N"
1863 >Next</A
1864 ></TD
1865 ></TR
1866 ><TR
1867 ><TD
1868 WIDTH="33%"
1869 ALIGN="left"
1870 VALIGN="top"
1871 >Testing Guidelines</TD
1872 ><TD
1873 WIDTH="34%"
1874 ALIGN="center"
1875 VALIGN="top"
1876 >&nbsp;</TD
1877 ><TD
1878 WIDTH="33%"
1879 ALIGN="right"
1880 VALIGN="top"
1881 >Update the Webserver</TD
1882 ></TR
1883 ></TABLE
1884 ></DIV
1885 ></BODY
1886 ></HTML
1887 >