wx.NET Release Checklist

A simple checklist for wx.NET team members doing a new release. Recommend printing out and using the old pen-through-line method to check off finished steps.

Determine whether a new version of wxWidgets will be used
Update wx.NET and wxWidgets release version number in various places
1. In WXNET_TOP/Src/wx.NET/AssemblyInfo.cs: edit AssemblyVersion
2. In WXNET_TOP/Dist/Defs.in.master: edit VERSION
3. Edit default pathnames in the various built Defs.in.template files:
  1. WXNET_TOP/Build/Linux/Defs.in.template
  2. WXNET_TOP/Build/MacOSX/Defs.in.template
  3. WXNET_TOP/Build/Windows/VS.NET/Defs.in.template
4. Review Docs/Manual now, as it gets bundled into the binary and source packages
5. Commit changes to CVS
Build and test on each platform:
1. Update from CVS, of course!
2. Update WXNET_TOP/Build/PLATFORM/Defs.in as necessary to account for any new wxWidgets version
3. If building a new wxWidgets, on Windows remember to edit both WXW_TOP/include/wx/msw/setup.h and WXW_TOP/build/msw/config.vc
4. Follow build instructions and make wxw (if necessary) and wxnet
5. On Windows, remember to run the separate Samples and Utils VS.NET solutions to build these pieces
6. On Windows, re-compile Demos/FreeCell and then commit the new binary Bin/FreeCell.exe to CVS
7. Test samples on all platforms
Create and upload packages:
1. Everything is done in WXNET_TOP/Dist
2. On the Linux host to a "make linux src" to create Linux binary package and generic source package
3. On the Mac host do a "make mac"
4. On the Windows host within a Cygwin shell do a "make win"
5. Test the above
6. Upload archives to SF by running "make upload" on each platform. This will not formally release the files, but will instead make them available to step 6.
Create/edit release notes at WXNET_TOP/Docs/WebSite/release/MAJOR-VERSION/index.html. If the release is a minor release such as 0.7.1, 0.7.2, etc. we usually just update the existing major release file, with newer release at the top.
Release to SourceForge
1. Create a new numbered release at the SF release page
  1. Paste in the the release notes (optional)
  2. Paste the latest bits from WXNET_TOP/Dist/temp/ChangeLog.txt (optional)
  3. Click Submit/Refresh
  4. Scroll down and click the checkboxes next to all the release files that got uploaded and click the "Add Files ..." button
  5. Now the fun part: define the processor and file type for each package. IMPORTANT: you must define and click the Update/Refresh button for each package individually one at a time, as they don't work globally :-(
  6. Once done, send a notice to those who are watching (optional)
Update Website under WXNET_TOP/Docs/WebSite
1. Link in the release to the home page at index.html (usually just a cut/paste job + tiny edits of a previous release). Be sure to adjust any link the SF download page for the release (which can be found by clicking here and then "show only this package").
2. Link in the new release notes created in step 5 to release/index.html (may not be necessary for minor release)
3. Modify the SF download links in binary.html (3 edits) and source.html (1 edit): I just look for the old release versions and update it by hand or globally
4. Commit changes
5. Publish onto SF Webserver by executing the following:
  ssh wxnetadmin@shell.sf.net update-cvs-snapshot
  This will copy the Website from CVS to the project's Apache document root
6. Update the API reference and user manual on the Website by doing the following:
  cd WXNET_TOP/Build/Linux make apiref doc-upload
  This currently requires the PNET toolset because it's csdoc tool is used
7. Test the download links changed above and the user manual on wxnet.sf.net
Tell the world! Send an announcement to wxnet-users@lists.sourceforge.net

Last changed on $Date: 2005/07/25 21:02:32 $ by $Author: t9mike $ • Original Author: Michael S. Muegel