- Working with the the wxWidgets release system
- =====================================
-
-Currently, to generate the release tarballs, wxWidgets uses a script which
-reads from a series of manifest files to determine which files should be
-installed for a particular port. This document explains how to alter the list
-of files that are distributed in the release tarballs.
-
-The scripts are located in the <wxWidgets root>/distrib/scripts folder, with
-create_archives.sh doing most of the work to create the actual tarballs.
-pre-flight.sh runs the entire process of doing a checkout, building the releases,
-and putting them into the <wxWidgets root>/deliver folder. The manifest files
-are located in the <wxWidgets root>/distrib/scripts/manifests folder and
-they have a .rsp extension for historical reasons.
-
-
-Adding/removing a file from releases
-------------------------------------
-
-First, you must decide which tarballs you'd like to make the change to, in
-order to determine which manifest file(s) the file should appear in.
-
-Below is a list of each port and the primary manifest files that are used to
-generate that release. The "ALL" in the list is not for wxALL, it means that
-those manifests are where things that go in all ports should be.
-
-tarball primary manifests
-------- ----------------
-ALL generic.rsp
-wxBase base.rsp
-wxMSW msw.rsp, wince.rsp
-wxOS2 os2.rsp
-wxGTK gtk.rsp
-wxMAC mac.rsp cocoa.rsp
-wxMotif motif.rsp
-wxMGL mgl.rsp
-wxX11 x11.rsp
-
-Once you've decided which manifest file is most appropriate to add your file
-in, then open that manifest and add a line with your file(s) at the bottom.
-The file(s) should give the path relative to the wxWidgets root directory,
-like so:
-
-docs/tech/tn0033.txt
-
-At the current time, wildcards in filenames are also accepted. Once the files are
-added, they should show up in releases when distrib/scripts/pre-flight.sh is run.
+ Making a new wxWidgets release
+ ==============================
+Before making the release
+-------------------------
+Update docs/readme.txt. Please review its contents in addition to just
+changing the version number.
+
+Put a date on the release line in docs/changes.txt.
+
+Update the date in the manual (docs/doxygen/mainpages/manual.h).
+
+Update the release announcement post in docs/publicity/announce.txt.
+
+
+Creating release files
+----------------------
+
+Currently our release system uses a Python 2.x script to generate releases.
+The script requires Unix utilities such as tar, zip and unix2dos and thus must
+be run either on Unix or using Cygwin on Windows. To generate a release, simply
+run the following command:
+
+build/tools/create-archive.py --compression=all /path/to/output/dir
+
+This will produce zip, gzip and bzip archives of the tree (without
+"compression" argument only .gz is made). Note that this commands produces huge
+amounts of output so redirecting it to a file is recommended.
+
+To add a prefix to the release, such as RC1, the SVN revision, or a date, just
+pass --postfix="postfix" to the script. More info on the options and their
+possible values can be found by calling `create-archive.py --help`.
+
+IMPORTANT NOTE: You *must* run this script from a clean source tree, that is,
+ with no junk files in it or modifications. This is because the
+ release should be a pristine copy of the tree as of the time of
+ release. If you have legitimate modifications in the tree that need
+ to be in the release, commit them first.
+
+To generate the windows installer (.exe) and the documentation files (chm and htb formats)
+run:
+
+build\tools\bld_chm_exe.bat
+
+which depends on the wxwidgets.iss file, and generates output in the %DAILY% directory. It
+assumes a clean copy of the wxWidgets source tree in %INNO%. Temporary files will be generated
+in the tree from which the batch file is run. It depends on doxygen, a number of gnu
+win32 tools and Microsofts htmlhelp compiler. The wxwidgets.iss file should not need
+editing, but you will want to check that the bld_chm_exe.bat has the correct version number.
+
+
+
+Alternative non official release scripts
+----------------------------------------
+
+If you use git-svn, then you can use alternative script that avoids the
+problems such as using non-clean tree and also has better handling of the ends
+of lines conversions. To use it you need to run
+
+- build/tools/svn-find-native-eols.pl
+- build/tools/git-make-release
+- build/tools/make-html-docs
+
+(the last one can also be used without git).
+
+
+Uploading
+---------
+
+Upload the files to SourceForge. This can be done via the web interface or just
+scp to sfusername,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z
+The following files need to be uploaded:
+
+ wxMSW-Setup-2.9.3.exe
+ wxWidgets-x.y.z.7z
+ wxWidgets-x.y.z.tar.bz2
+ wxWidgets-x.y.z.zip
+ wxWidgets-x.y.z_Headers.zip
+ wxWidgets-docs-chm-x.y.z.zip
+ wxWidgets-docs-html-x.y.z.tar.bz2
+ wxWidgets-docs-html-x.y.z.zip
+
+You will need to use the web interface to mark the latest uploaded files as
+being "default downloads" for the appropriate platforms (.zip or .exe for MSW,
+.tar.bz2 for everything else) as otherwise SourceForge would continue to suggest
+people to download old files.
+
+Next, update (at least the versions and SHA1 sums, but maybe more) and upload
+docs/release_files.mdwn and docs/release_binaries.mdwn files. They need to be
+renamed to README.md on SF to be shown when the directory is viewed, i.e. do:
+
+ scp docs/release_files.mdwn \
+ sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z/README.md
+ scp docs/release_binaries.mdwn \
+ sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z/binaries/README.md
+
+And upload the change log too:
+
+ scp docs/changes.txt \
+ sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z
+
+
+Also upload the files to the FTP mirror at ftp.wxwidgets.org (ask Chris for
+access if you don't have it).
+
+Create http://docs.wxwidgets.org/x.y.z/ (ask Bryan to do it if not done yet).
+
+
+Announcement
+------------
+
+Post docs/publicity/announce.txt at least to wx-announce@googlegroups.com.
+
+TODO: where else to announce it?
+
+Update www.wxwidgets.org, usually a news item is enough but something more can
+be called for for major releases.
+
+Also update downloads/index.html to mention the new latest release.
+
+Post to wxBlog if necessary.
+
+
+Version updates
+---------------
+
+Trac: mark the milestone corresponding to the release as completed and add a
+new version for it to allow reporting bugs against it and create the next
+milestone (ask Vadim or Robin to do it or to get admin password).
+
+Run misc/scripts/inc_release to increment micro version, i.e. replace x.y.z
+with x.y.z+1 (minor or major versions updates require manual intervention).
projects / wxWidgets.git / blobdiff