This is an old revision of the document!


Release Process

Plan the Release

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

Test a Release Build

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.)

At the command line, use svn log to find out the current revision:

$ svn log -l1
------------------------------------------------------------------------
r13710 | tedfelix | 2014-06-03 15:46:54 -0400 (Tue, 03 Jun 2014) | 4 lines

Set note-off velocity to 64

As recommended by the MIDI spec.  See bug #1426.

------------------------------------------------------------------------

In a working copy, do an svn log to see the log entries since that revision.

svn log -r 13662:13710

Or, on the sourceforge site: Code > trunk > rosegarden:

http://sourceforge.net/p/rosegarden/code/HEAD/tree/trunk/rosegarden/

Then click the “History” button in the upper right. The list is in reverse order, so scroll down to the revision of the last release. Then work your way up through the commits.

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.

Update CMakeLists.txt

Check/adjust the codename/version number in CMakeLists.txt.

The codename/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

See acpid release process for details.

  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.

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.

  • /website/getting/source/index.shtml
    • Update link to the current stable release.
  • /website/subleft.html
    • Add a new “newsheadline”.
  • /website/index.shtml
    • Update version.
    • Copy in release notes summary.
    • Update link to release notes on wiki.
  • /website/latest-version.txt
    • Update version number.
  • /website/resources/authors/index.shtml
    • Add any new authors.

Test, commit, 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.1491869012.txt.gz · Last modified: 2022/05/06 16:07 (external edit)
Recent changes RSS feed Creative Commons License Valid XHTML 1.0 Valid CSS Driven by DokuWiki