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