doc/webserver/developer-manual/newrelease.html

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