wiki:MilestoneReleasesHowTo

Version 30 (modified by planetcruiser, 6 years ago) (diff)

added test link

How to release a milestone

Follow these steps:

  1. Review tickets and code
    • Make sure all tickets are closed and tested
    • Go through all tickets once again and review if the solution solves the issue initially reported in the ticket description, issues reported in the ticket comments are of secondary concern. Reopen tickets that have not fully been solved
    • If grave new issues are raised in the ticket comments, make sure new tickets have been created and that those tickets mention the current ticket in the "Related tickets" part
    • Look through commits and ensure that newly added and changed code follows the ProgrammingGuideline. If not, contact the committer or fix it yourself. But this should not delay the release, so this is mainly intended as a notice for future commits
  2. Make sure to break caches
    • A common source of errors are outdated versions of JavaScript and CSS files in users' caches after a release. We address this by adding "?1" or increments of it to resource file includes. Find out which resource files have been modified since the last major release by typing this:
      git checkout master
      git pull
      git checkout develop
      git pull
      git diff --name-only --diff-filter=M master | egrep "\.(js|css)"
      
    • Do a full text search for the filenames you get above and make sure they got a "?1" (or higher) at the end, for example searchmembers.js?1 in main.js.
    • For bigger releases it might be wise to test cache breaking by following this example: http://lists.bewelcome.org/pipermail/bw-dev-discussion/2012-December/009961.html
  3. Write changelog
    • Create new wiki page for changelog, naming convention is "Changelog_x.x", see Changelog_0.7 for example and use Changelog_x.x as a template.
    • Where possible use past tense verbs to describe changes, so it's clear what has been done. Start lines with "Added", "Changed", "Fixed" and "Removed". The ticket title itself often is not enough to describe a change.
    • First list all "Added" items, because that's what most people are interested in, then "Changed" functionality. "Fixed" and "Removed" go last, because users expect things to work anyway and removed items should only be removed if their disappearance won't be noticed, so they are not so important in the list.
    • If there is a ticket for the change, link to it at the end of the line: "(ticket #666)".
    • Check https://gitorious.org/bewelcome/rox/commits/develop for commits since last release that have no ticket and add them as well and add "(no ticket)" at the end
    • Thank contributing users by stating their BeWelcome user name, not their trac name. Use alphabetical order to stay neutral. Check in commits and ticket comments for code contributors and testers. Don't forget anyone! ;)
    • Edit milestone page and add link to changelog, see 0.7 for example.
  4. Merge develop into master
    git pull
    git checkout master
    git merge --no-ff develop
    git push
    
  5. Add tag for release, for example:
    git tag -a v0.7 -m "Bugfixing and feature release 0.7"
    git push --tags
    
  6. Deploy www from master via deploy.sh on puma (pending documentation, can currently only be done by planetcruiser and jsfan)
  7. Make sure cron jobs (e.g. mailbot) run without errors, check bw-admin mailing list for error reports
  8. Edit milestone and tick "Completed"
  9. Write about release via blog post in community news
  10. Announce new/modified translation strings in this thread: http://www.bewelcome.org/groups/60/forum/s2330
  11. Announce release (with link to community news blog post):