Release Process

Plan the Release

  1. Pick a release date.
  2. Schedule a string freeze and translation period prior. One week is fine.
  3. Schedule a testing (feature freeze) period. Four weeks is good.
  4. Announce the schedule.

Feature Freeze

On the day of the feature freeze…

  • Put together a testing notes page for the new version on the wiki. See 21.06 Testing Notes.
  • Send a “Testing Appreciated” email to the user list.
  • Make a “Testing Appreciated” post on f-book.
  • Run the unit tests with make test.
  • Perform a regression test.

String Freeze

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:

$ git commit -am "Update .ts files for 21.06 (scripts/make-ts)"
$ git push

Announce the string freeze/start of the translation period.

Release Eve

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

Pending Changes

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

File Format Version

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.

Testing

On the release date…

  • From a debug build, do make test to run unit tests.
  • Do a Release build and a regression test.

Update CHANGELOG

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 CHANGELOG to reflect the commits since the last release. Wrap to 72 columns for email.
  • Copy the latest version to a new page on the wiki.

Update appdata

Add release notes for the new release to the appdata file:

data/appdata/rosegarden.appdata.xml

Validate with appstreamcli:

appstreamcli validate data/appdata/rosegarden.appdata.xml

Update the README

Update copyright year as needed.

Update anything else that seems like it needs updating.

Update AboutDialog.cpp

Update copyright year as needed.

Update data.qrc

Run “scripts/rebuild-qrc-nosvn” 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 should have been bumped after the last delivery, so this should be OK.

Commit Changes

If needed:

git commit -am "Updates for version xx.xx"
git push

Create tarball

Download a snapshot from the git repo page on SourceForge.

cd to where the snapshot was saved and run the make-release-tarball script with the name of the snapshot:

<path-to-source>/scripts/make-release-tarball <snapshot-name>.zip

Test tarball

Sanity test the tarball. Build and run from it.

Tag the Release

From the sourcebase…

git tag -m "Release" xx.xx
git push --tags

Deliver

  1. Create new version directory on sf
  2. Upload the tarball to sf
  3. Upload the current version section of the CHANGELOG to sf as README.
  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 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…?

Point Release Process

Discussion uses 21.06.1 as an example.

Check out a “point” branch based on the tag you want to start at.

git checkout -b point 21.06

Cherry-pick any commits you need.

git cherry-pick 9713720e

Go back through the release process carefully. Some things to watch out for:

  1. Start at Testing.
  2. Update the CHANGELOG notes with a complete new point release.
  3. Version will need to be adjusted in CMakeLists.txt.
  4. You will need to push the point branch in order to generate a tarball. You can always delete it later.
  5. No need for a new version directory on sf.
  6. No need to bump the version number after the tarball.

Delete the point branch local and remote once the tags are pushed.

See also

 
 
dev/release_process.txt · Last modified: 2021/07/10 18:32 by tedfelix
Recent changes RSS feed Creative Commons License Valid XHTML 1.0 Valid CSS Driven by DokuWiki