How to make an Agavi release

  1. Switch off XDebug (it makes things horribly slow)
  2. Run unit tests for Agavi
  3. Run unit tests for the Sample app
  4. Make sure the CHANGELOG is complete and all changes from previous versions that are still maintained have been merged in
  5. Write the RELEASE_NOTES
  6. Add correct version numbers and release dates to changelog and release notes
    • use "November ??, 2009" etc in release notes if the release is not a stable one
  7. Check for consistency with previous changelog entries
    • whitespace
    • date format
    • version number format
    • type order
      1. SEC
      2. ADD
      3. CHG
      4. FIX
    • two blank lines between releases; one blank line for
      • separating ADD/CHG/FIX
      • separating heading and content
    • check correct heading length
  8. Add version info to etc/phing/AgaviPackageTask.php
    • "1.0.1RC1" etc
    • beta/beta stability for beta and RC releases, otherwise stable
  9. Add version info to src/version.php
    • comment out "status" for stable releases
    • check "branch"
  10. Update TODO and KNOWN_ISSUES
  11. Check everything in
  12. svn export the branch from the server (so externals are included) to a separate folder called sth like 1.2.1RC2
  13. tar czf 1.2.1RC2.tgz 1.2.1RC2
  14. zip -r 1.2.1RC2.zip 1.2.1RC2
  15. Make a PEAR package; you need PEAR_PackageFileManager2 installed and agavi.org and other channels have to be discovered first
    1. cd 1.2.1RC2
    2. phing package-pear
    3. cd pear-build/ (build in 0.11)
    4. pear package
  16. Test the PEAR package (install, then make new project and open it in your browser)
  17. svn tag the release
  18. Set version info back to -dev in src/version.php, increment the version number if necessary, and check in
  19. Upload .zip and .tgz to web server
  20. Upload .zip and .tgz to Ohloh
    1. Mind the release dates
  21. Upload PEAR package to pear.agavi.org
  22. Add new version with release date (not time) to Trac
    • make it default if applicable (latest version on current release series)
  23. Add a new milestone for next version in series to Trac, if necessary
    • make it default if applicable (i.e. if milestone for current release series)
  24. Mark version milestone as complete in Trac, if necessary
    • mind the date
  25. Announce on
    • Website
      • Home page
      • Downloads page
    • Trac (index page with links)
    • Mailing Lists
      • announce
      • dev
      • users
    • IRC (channel topic)
    • Xing group
    • Blog
    • Ohloh Journal
    • Wikipedia (for stable releases and for preview releases, where applicable)
    • Freshmeatscrew Freshmeat
  26. Add entire CHANGELOG section for this release to newer branches' CHANGELOG-x.y files
  27. Add entire RELEASE_NOTES section for this release to newer branches' RELEASE_NOTES-x.y files (if it's a stable release)