Release Process

Plan the Release

  1. Pick a release date.
  2. Schedule a string freeze and translation period prior.
  3. Announce the schedule.

String Freeze

On the day of the string freeze, run scripts/make-ts to update the ts files for the translators. Commit this and then announce the string freeze/start of the translation period.

Test a Release Build

On the release date, do a Release build and a few sanity checks to make sure nothing is broken.

Update Release Notes

Make a note of the svn revision of the last release. E.g. for release 14.02, the revision according to the tags was 13662. (Note that this might not match up since the tags can be made long after the release. However, with the current build script this should only be “off by one” from the actual revision.)

In a working copy, do an svn log to see the log entries from the previous release to the latest.

$ svn log -v -r 13662:HEAD | less

An alternative would be to browse the commits on sourceforge. I find it cumbersome, however.

Update the release notes to reflect the commits since the last release.

http://www.rosegardenmusic.com/wiki/dev:next_version

When finished, move the release notes from the “Upcoming Release” page on the wiki to an official versioned release notes page on the wiki.

Consider including the release notes within the tarball in the future. Maybe just accumulate them in a single file. What do other projects do? Changelog!

Update the README

Update copyright year as needed.

Update anything else that seems like it needs updating.

Update data.qrc

Run “scripts/rebuild-qrc” to make sure the data.qrc file is up-to-date.

Check Code Name and Version

Check/adjust the code name/version number in CMakeLists.txt.

The code name/version number will be bumped after delivery.

Commit Changes

svn commit -m "Updates for version xx.xx"

Create tarball

Use the make-release-tarball script:

scripts/make-release-tarball RELEASE

Sanity test the tarball. Build and run from it.

Deliver

  1. Create new version directory on sf
  2. Upload the tarball to sf
  3. Upload the release notes to sf as README
  4. Update sourceforge to point to the new version. Use the “i” icon to the right of the file.

Update Website

Update the website to point to the new version. The website can be updated by committing changes to the website directory in svn. These are automatically uploaded to the web server. The webpages use Server Side Includes (SSI), so you'll need to set up a web server to test before uploading changes.

  • /website/subleft.html (main page on the left)
    • Add a new “newsheadline”.
  • /website/resources/authors/index.shtml
    • Add any new authors.

Test, commit, wait for the auto upload (takes a while), and test.

See https://sourceforge.net/p/rosegarden/code/14701/ for an example.

Update CMakeLists.txt

Bump the version number and codename.

Commit.

Announce

  • user list
  • dev list?
  • facebook
  • twitter?
  • etc…?

See also

 
 
dev/release_process.txt · Last modified: 2017/10/08 02:12 by tedfelix
Recent changes RSS feed Creative Commons License Valid XHTML 1.0 Valid CSS Driven by DokuWiki