X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/c7f200e9c533d10a3277292272f1d757ec602d39..27e8395ed0a44338796ea5c4ec48ddd00fa9ec4e:/docs/tech/tn0022.txt diff --git a/docs/tech/tn0022.txt b/docs/tech/tn0022.txt index 591e0c6933..65bfbb1c87 100644 --- a/docs/tech/tn0022.txt +++ b/docs/tech/tn0022.txt @@ -1,49 +1,133 @@ - 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 /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 /deliver folder. The manifest files -are located in the /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).