tn0022.txt 6.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172
  1. Making a new wxWidgets release
  2. ==============================
  3. Before making the release
  4. -------------------------
  5. Change the version in include/wx/version.h.
  6. Update docs/readme.txt. Please review its contents in addition to just
  7. changing the version number.
  8. Put a date on the release line in docs/changes.txt.
  9. Update the date in the manual (docs/doxygen/mainpages/manual.h).
  10. Update the release announcement post in docs/publicity/announce.txt.
  11. Creating release files
  12. ----------------------
  13. The currently used release scripts need to be used from git-svn checkout and
  14. rely on Git to avoid problems with using non-clean trees and such. If you don't
  15. use Git you may use the alternative archive creation scripts in the next
  16. section.
  17. Follow these steps assuming the current working directory is the root of git
  18. working copy and you want to prepare distribution for the version x.y.z:
  19. 1. Run "./build/tools/svn-find-native-eols.pl > ../eol-native" (if you have
  20. an existing svn checkout, pass it to the script to make it run much faster,
  21. but take care to have up to date sources in the working tree).
  22. 2. Run "./build/tools/git-make-release x.y.z" to create source archives
  23. ../wxWidgets-x.y.z.{7z,tar.bz2,zip} and wxWidgets_x.y.z_Headers.zip.
  24. 3. Run "./build/tools/make-html-docs x.y.z" to create HTML documentation
  25. archives ../wxWidgets-x.y.z.{tar.bz2,zip}
  26. 4. This step must be done under Windows as it relies on having hhc.exe, the
  27. Html Help compiler, in PATH: run the following commands
  28. cd docs\doxygen
  29. regen.bat chm
  30. cd out
  31. zip ..\..\..\wxWidgets-x.y.z-docs-chm.zip wx.chm
  32. 5. This step also must be done under Windows as it uses Inno Setup to produce
  33. the .exe file and it also requires the CHM file built above:
  34. md x.y.z-sources
  35. cd x.y.z-sources
  36. 7z x ..\wxWidgets-x.y.z.7z
  37. md docs\htmlhelp
  38. cp ..\docs\doxygen\out\wx.chm docs\htmlhelp
  39. set WXW_VER=x.y.z
  40. iscc build\tools\wxwidgets.iss
  41. Instructions for the previous version of release scripts
  42. --------------------------------------------------------
  43. NB: These scripts haven't been used since 2.8 series and may not work any longer!
  44. Currently our release system uses a Python 2.x script to generate releases.
  45. The script requires Unix utilities such as tar, zip and unix2dos and thus must
  46. be run either on Unix or using Cygwin on Windows. To generate a release, simply
  47. run the following command:
  48. build/tools/create-archive.py --compression=all /path/to/output/dir
  49. This will produce zip, gzip and bzip archives of the tree (without
  50. "compression" argument only .gz is made). Note that this commands produces huge
  51. amounts of output so redirecting it to a file is recommended.
  52. To add a prefix to the release, such as RC1, the SVN revision, or a date, just
  53. pass --postfix="postfix" to the script. More info on the options and their
  54. possible values can be found by calling `create-archive.py --help`.
  55. IMPORTANT NOTE: You *must* run this script from a clean source tree, that is,
  56. with no junk files in it or modifications. This is because the
  57. release should be a pristine copy of the tree as of the time of
  58. release. If you have legitimate modifications in the tree that need
  59. to be in the release, commit them first.
  60. To generate the windows installer (.exe) and the documentation files (chm and htb formats)
  61. run:
  62. build\tools\bld_chm_exe.bat
  63. which depends on the wxwidgets.iss file, and generates output in the %DAILY% directory. It
  64. assumes a clean copy of the wxWidgets source tree in %INNO%. Temporary files will be generated
  65. in the tree from which the batch file is run. It depends on doxygen, a number of gnu
  66. win32 tools and Microsofts htmlhelp compiler. The wxwidgets.iss file should not need
  67. editing, but you will want to check that the bld_chm_exe.bat has the correct version number.
  68. Uploading
  69. ---------
  70. Upload the files to SourceForge. This can be done via the web interface or just
  71. scp to sfusername,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z
  72. The following files need to be uploaded:
  73. wxMSW-Setup-x.y.z.exe
  74. wxWidgets-x.y.z.7z
  75. wxWidgets-x.y.z.tar.bz2
  76. wxWidgets-x.y.z.zip
  77. wxWidgets-docs-chm-x.y.z.zip
  78. wxWidgets-docs-html-x.y.z.tar.bz2
  79. wxWidgets-docs-html-x.y.z.zip
  80. The file wxWidgets-x.y.z_Headers.7z should be uploaded to binaries
  81. subdirectory as it's only useful when using pre-built binaries.
  82. You will need to use the web interface to mark the latest uploaded files as
  83. being "default downloads" for the appropriate platforms (.zip or .exe for MSW,
  84. .tar.bz2 for everything else) as otherwise SourceForge would continue to suggest
  85. people to download old files.
  86. Next, update (at least the versions and SHA1 sums, but maybe more) and upload
  87. docs/release_files.mdwn and docs/release_binaries.mdwn files. They need to be
  88. renamed to README.md on SF to be shown when the directory is viewed, i.e. do:
  89. scp docs/release_files.mdwn \
  90. sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z/README.md
  91. scp docs/release_binaries.mdwn \
  92. sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z/binaries/README.md
  93. And upload the change log too:
  94. scp docs/changes.txt \
  95. sfuser,wxwindows@frs.sf.net:/home/frs/project/w/wx/wxwindows/x.y.z
  96. Also upload the files to the FTP mirror at ftp.wxwidgets.org (ask Chris for
  97. access if you don't have it).
  98. Create http://docs.wxwidgets.org/x.y.z/ (ask Bryan to do it if not done yet).
  99. Announcement
  100. ------------
  101. Post docs/publicity/announce.txt at least to wx-announce@googlegroups.com.
  102. Submit a link to http://www.reddit.com/r/programming
  103. For major releases, submit the announcement to http://slashdot.org/submission
  104. Update www.wxwidgets.org, usually a news item is enough but something more can
  105. be called for for major releases.
  106. Also update downloads/index.html to mention the new latest release.
  107. Post to wxBlog if necessary.
  108. Announce on Google+/Twitter/whatever the person doing the release prefers (we
  109. don't have "official" wxWidgets account, should we?).
  110. Version updates
  111. ---------------
  112. Trac: mark the milestone corresponding to the release as completed and add a
  113. new version for it to allow reporting bugs against it and create the next
  114. milestone (ask Vadim or Robin to do it or to get admin password).
  115. Run misc/scripts/inc_release to increment micro version, i.e. replace x.y.z
  116. with x.y.z+1 (minor or major versions updates require manual intervention).