wiki:ReleaseProcess

Version 1 (modified by Dominic Hargreaves, 15 years ago) (diff)

--

This is the process the release manager goes through to release

  1. Call a feature freeze on the mailing list
  2. See if the test suite passes. If not, find, fix and commit.
  3. Take a diff from the previous release eg:
    svn diff https://urchin.earth.li/svn/openguides/tags/rel0_58 https://urchin.earth.li/svn/openguides/trunk
    
    and put it into a temp file.
  4. Work through the diff with an editor, deleting as you go and chasing up any changes that don't make sense or need adjustment. The idea is that you end up with an empty file when you've reviewed it all.
  5. During the above process you will probably have found bugs, and fixed them. Commit that.
  6. See if the test suite passes. If not, find, fix and commit.
  7. Check that the following files are up-to-date:
    • Changes
    • UPGRADING
    • MANIFEST (file lists)
    • Build.PL (file lists and module dependencies)
    • PREREQUISITES (module dependencies)
  8. Update any year numbers in the copyright notices if the year has changed and the file has been updated
  9. Update the version number in wiki.cgi and lib/OpenGuides.pm
  10. Make an internal release candidate:
    perl Build.PL
    perl Build dist
    
  11. From that release candidate, test a new install and an upgrade
  12. Do some user testing on that install; fix any bugs encountered
  13. See if the test suite passes. If not, find, fix and commit.
  14. Add a date to the version in Changes
  15. Tag the release
  16. Run utils/build-tarball-from-svn-tag to make the tarball