Release Process

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

On the day of the string freeze, update the .ts files for the translators. We are now standardized on Qt5, so make sure that is the current version of Qt.

$ QT_SELECT=qt5 scripts/make-ts 

Commit this:

$ svn commit -m "Update .ts files for xx.xx (scripts/make-ts)"

Announce the string freeze/start of the translation period.

On the eve of the release, send out a reminder for any last minute contributions and translations.

Check email for any pending changes or requests that need to be included in this release. Make those changes as appropriate.

Determine whether any changes have been made to the .rg file format. If so, decide the extent of those changes and what level of file format version update is required. Update the file format version as appropriate. See comments on FILE_FORMAT_VERSION_POINT in RosegardenDocument.cpp.

Changing the point version has no effect on anything as it is ignored. Changing the minor version will cause an “incompatibilities” warning on load, but the file will be loaded. Use this when data might be lost when opening a file with an older version of rg (e.g. new fields have been added). Changing the major version will cause older versions of rg to refuse to load the file. Obviously, we should avoid this at all costs. The chances are good that we will never have to do this.

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

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.

Related to the release notes is the appdata file. This can be found in data/appdata. This needs to be updated as well.

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 copyright year as needed.

Update anything else that seems like it needs updating.

Update copyright year as needed.

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

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

The code name/version number will be bumped after delivery, so this should be OK.

If needed:

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

Use the make-release-tarball script:

scripts/make-release-tarball RELEASE

The make-release-tarball script will tag the release from trunk. This is correct for non-point releases.

For point releases, we need to tag the release from the stable branch:

svn copy svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/branches/stable-17.12 \
         svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/tags/rosegarden-17.12.1 \
         -m "Tag release 17.12.1"

We might upgrade make-release-tarball to accept a “POINT” option that will change the tagging behavior. Or we might be able to parse the output of svn info and use that to generate the two URLs for tagging. That should fix the 502 errors.

For some reason, I get a lot of errors during the tagging process.

An “Unexpected HTTP status 502 'Bad Gateway'” error indicates that the URL used to create the tag doesn't match the URL used to checkout the repo. Use svn info to figure out what URL type to use:

$ svn info .
...
URL: svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/branches/stable-17.12
Relative URL: ^/branches/stable-17.12
Repository Root: svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code
...

From the above we know that we need to use an “svn+ssh” style URL to create a tag.

It might prompt for password, you can cancel that. This might drop to the command line and prompt for a password. I usually enter it here and get a ton of errors. It still seems to work.

Any errors related to a “wallet” can safely be ignored and the wallet UI can safely be closed via the “cancel” button.

Sanity test the tarball. Build and run from it.

1. Create new version directory on sf
2. Upload the tarball to sf
3. Upload the release notes to sf as README. Wrap to 72 columns for email.
4. Update sourceforge to point to the new version. Use the “i” icon to the right of the file. Set “Default Download For:” to Tux. Set “Download Button:” text to “Rosegarden xx.xx”.

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/getting/source/index.shtml (http://www.rosegardenmusic.com/getting/source/index.shtml)
  • Update link to the current stable release.

• /website/subleft.html (main page on the left)
  • Add a new “newsheadline”.

• /website/index.shtml (http://www.rosegardenmusic.com/)
  • Update version.
  • Copy in release notes summary.
  • Update link to release notes on wiki.

• /website/latest-version.txt (http://www.rosegardenmusic.com/latest-version.txt)
  • Update version number.

• /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.

Bump the version number and codename.

Commit.

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

Discussion uses 17.12.1 as an example.

In svn a tag will move if you commit to it, so we will need to create a stable-17.12 branch from 17.12 so that we can make changes. Then we can do the usual tagging process on that branch to tag it for release.

svn copy https://svn.code.sf.net/p/rosegarden/code/tags/rosegarden-17.12 \
         https://svn.code.sf.net/p/rosegarden/code/branches/stable-17.12 \
         -m "Create stable-17.12 branch."

Checkout stable-17.12 someplace. Replace “tedfelix” with your sf userid.

svn checkout --username=tedfelix \
    svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/branches/stable-17.12 \
    stable-17.12

Cherrypick the various commits you need into the stable branch. Use svn merge to cherrypick. Cherrypicking a single commit:

svn merge -c 15189 ^/trunk/rosegarden

You'll need to commit that. Since svn doesn't bring in any information from the original commits, you'll want to include a list of revisions in the commit message. Format them with square brackets to get hyperlinks in sf: [r15189].

Finally, go back through the release process with the following changes:

1. Start at Test a Release Build.
2. Update the release notes with a new point release fixes section at the top. E.g. “Fixes for 17.12.1”.
3. Version will need to be adjusted in CMakeLists.txt.
4. No need for a new version directory on sf.
5. No need to bump the version number after the tarball.

Release