Release Process

1. Pick a release date.
2. Schedule a string freeze and translation period prior. TWO WEEKS this time as requested by the translators.
3. Schedule a testing (feature freeze) period. Four weeks is good.
4. Announce the schedule.

You can examine the commit history since the previous release in git using the command line:

$ git checkout master
$ git log --stat --reverse 22.12..

…or by using gitk. With gitk, you can enter the last release number in the “SHA1 ID:” field and it will jump to that tag. Then work your way backwards (up).

The commit ordering for each of the above approaches is different. Not sure at this point which is better for writing a CHANGELOG.

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.

On the day of the feature freeze…

• Copy the latest version of the CHANGELOG to a new page on the wiki.
• [optional] 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.

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.

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. The key routines are:

• RosegardenDocument::saveDocument()
• RoseXmlHandler::startElement() (and others in RoseXmlHandler)
• Composition::toXmlString() (and other toXmlString() routines throughout the system)

Git should ferret out the changes:

git log -p -w src/document/RoseXmlHandler.cpp src/document/RosegardenDocument.cpp src/base/Composition.cpp

If changes have been made to the file format, 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. Use this for things that might be annoying, but won't result in data loss. 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.

Before the June release… Check for any single copyright years that need to be expanded to a range. E.g. “Copyright 2020 …”.

cd src
grep -rh --include="*" "Copyright .* Rosegarden development team" . | sort | uniq

Fix those manually to include the current year.

From within the src directory, run the update-copyright script.

../scripts/update-copyright

Finally, commit the changes as Copyright Bot:

git commit -a --author="Copyright Bot <copyright@rosegardenmusic.com>" -m "Update copyright"

Search for any logging that is turned on and turn it off.

grep -rnl --include="*.cpp" "^//#define RG_NO" src

• From a debug build, do make test to run unit tests.
• The tests may fail due to ASAN. grep for Totals to see the actual results:

$ grep Totals Testing/Temporary/LastTest.log

• Do a Release build and a regression test.

• Add any new changes to the CHANGELOG.
• Copy the latest version of the CHANGELOG to the wiki.

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

data/appdata/rosegarden.appdata.xml

Also update the copyright year at the top.

Validate with appstreamcli:

appstreamcli validate data/appdata/rosegarden.appdata.xml

Update copyright year as needed.

Update anything else that seems like it needs updating.

Update copyright year as needed.

Get the latest yoshimi.rgd file from https://github.com/lorenzosu/rosegarden_yoshimi_banks/

Copy it to data/library and make sure it is all lower-case “yoshimi.rgd” to match the previous version.

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

If needed:

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

Finally, on the release date…

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

Sanity test the tarball. Build and run from it.

From the sourcebase…

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

SourceForge

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.

GitHub

• Create a release.

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/index.shtml (http://www.rosegardenmusic.com/)
  • Update version.
  • Update link to release notes on wiki.

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

• /website/getting/source/index.shtml (http://www.rosegardenmusic.com/getting/source/index.shtml)
  • Update link to the current stable release.

• /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…?

• Bugs: Go through all “feedback” and close.
• Feature Requests: Go through all “feedback” and close.
• Patches: Go through all “feedback” and close.
• Close any merge requests that were accepted.

Discussion uses 22.12.1 as an example.

Create a new stable branch based on the tag you want to start at.

git checkout -b 22.12-stable 22.12

Cherry-pick any commits you need from master.

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 stable branch in order to generate a tarball.
5. No need for a new version directory on sf.
6. No need to bump the version number after the tarball.

Release