Differences

This shows you the differences between two versions of the page.

--- dev:release_process [2019/12/12 01:29]
tedfelix [Tagging Errors]
+++ dev:release_process [2025/12/03 15:59] (current)
tedfelix [Update Website]
@@ Line 1: / Line 1: @@
 ====== Release Process ======
 ===== Plan the Release =====
   - Pick a release date.
-  - Schedule a string freeze and translation period prior.  One week is fine.
+  - Schedule a string freeze and translation period prior.  TWO WEEKS this time as requested by the translators.
+  - Schedule a testing (feature freeze) period.  Four weeks is good.
   - Announce the schedule.
+===== Update CHANGELOG =====
+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.
+===== Feature Freeze =====
+On the day of the feature freeze...
+  * Review experimental, alpha, and beta test features and decide whether to promote them and/or enable them by default.
+  * Copy the latest version of the CHANGELOG to a new page [[:start#release_notes|on the wiki]].
+  * [optional] Put together a testing notes page for the new version on the wiki.  See [[dev:21.06_testing_notes|21.06 Testing Notes]].
+  * Send a "Testing Appreciated" email to the user list.
+  * Make a "Testing Appreciated" post on f-book.
+==== Regression Testing ====
+  * Run the unit tests with ''make test''.
+  * Perform a regression test.
+==== Update Copyright ====
+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"
 ===== String Freeze =====
+==== Update Translations and Announce ====
 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.
@@ Line 17: / Line 65: @@
 Commit this:
-  $ svn commit -m "Update .ts files for xx.xx (scripts/make-ts)"
+  $ 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 =====
+==== Review Translations ====
-On the eve of the release, send out a reminder for any last minute contributions and translations.
+As translators submit their translations, walk through the diff and check for obvious errors and leading/trailing space errors.  Use ''--color-words=.'' to get a character diff which is a lot faster to review for translations.  Reviewing on github works well too.
+  $ git log -p --color-words=. master..
-===== Pending Changes =====
+Run ts-untrans to find untranslated (blank translation) strings.
-Check email for any pending changes or requests that need to be included in this release.  Make those changes as appropriate.
+  $ scripts/ts-untrans data/locale/de.ts
+Manually review and mark each untranslated string as unfinished as appropriate:
-===== File Format Version =====
+  <translation type="unfinished">
-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.
+//Might be nice to upgrade ts-untrans to mark all blank as unfinished.  Then we can just review that and fix the ones that should be blank.//
+===== Release Eve =====
-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 eve of the release, send out a reminder for any last minute contributions and translations.
+==== Pending Changes ====
-===== Test a Release Build =====
+Check email for any pending changes or requests that need to be included in this release.  Make those changes as appropriate.
-On the release date, do a Release build and a few sanity checks to make sure nothing obvious is broken.
+==== File Format Version ====
-===== Update Release Notes =====
+Determine whether any changes have been made to the .rg file format.  The key routines are:
-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.)
+  * ''RosegardenDocument::saveDocument()''
+  * ''RoseXmlHandler::startElement()'' (and others in ''RoseXmlHandler'')
+  * ''Composition::toXmlString()'' (and other toXmlString() routines throughout the system)
-In a working copy, do an svn log to see the log entries from the previous release to the latest.
+Git should ferret out the changes:
-  $ svn log -v -r 13662:HEAD | less
+  git log -p -w src/document/RoseXmlHandler.cpp src/document/RosegardenDocument.cpp src/base/Composition.cpp
-//An alternative would be to browse the commits on sourceforge.  I find it cumbersome, however.//
+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.
-Update the release notes to reflect the commits since the last release.
+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.
-  http://www.rosegardenmusic.com/wiki/dev:next_version
+==== Turn Off Logging ====
-When finished, move the release notes from the "Upcoming Release" page on the wiki to an official versioned release notes page on the wiki.
+Search for any logging that is turned on and turn it off.
-Related to the release notes is the appdata file.  This can be found in data/appdata.  This needs to be updated as well.
+  grep -rnl --include="*.cpp" "^//#define RG_NO" src
-//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!//
+==== Testing ====
+  * 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:
-===== Update the README =====
+  $ grep Totals Testing/Temporary/LastTest.log
-Update copyright year as needed.
+  * Do a release build with tests turned on and run the tests.
-Update anything else that seems like it needs updating.
+  $ mkdir build; cd build
+  $ cmake -DBUILD_TESTING=ON ..
+  $ make
+  $ make test
-===== Update AboutDialog.cpp =====
+  * Do a regression test against the release build.
-Update copyright year as needed.
+==== Finalize CHANGELOG ====
-===== Update data.qrc =====
+  * Add any new changes to the CHANGELOG.
+  * Copy the latest version of the CHANGELOG to the wiki.
-Run "scripts/rebuild-qrc" to make sure the data.qrc file is up-to-date.
+==== Update appdata ====
+Add release notes for the new release to the appdata file:
-===== Check Code Name and Version =====
+  data/appdata/rosegarden.appdata.xml
-Check/adjust the code name/version number in CMakeLists.txt.
+Also update the copyright year at the top.
-//The code name/version number will be bumped after delivery, so this should be OK.//
+Validate with appstreamcli:
+  appstreamcli validate data/appdata/rosegarden.appdata.xml
-===== Commit Changes =====
+==== Update the README ====
-If needed:
+Update copyright year as needed.
-  svn commit -m "Updates for version xx.xx"
+Update anything else that seems like it needs updating.
+==== Update AboutDialog.cpp ====
-===== Create tarball =====
+<del>Update copyright year as needed.</del>  (This is now set programmatically.  No change needed.)
-Use the make-release-tarball script:
+==== Update data.qrc ====
-  scripts/make-release-tarball RELEASE
+Get the latest yoshimi.rgd file from https://github.com/lorenzosu/rosegarden_yoshimi_banks/
-==== Tagging the Release ====
-The make-release-tarball script will tag the release from trunk.  This is correct for non-point releases.
+Copy it to data/library and make sure it is all lower-case "yoshimi.rgd" to match the previous version.
-For point releases, we need to tag the release from the stable branch:
+Run "scripts/rebuild-qrc-nosvn" to make sure the data.qrc file is up-to-date.
-  svn copy svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/branches/stable-17.12 \
+==== Check Code Name and Version ====
-           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.//
+Check/adjust the code name/version number in CMakeLists.txt.
-==== Tagging Errors ====
-For some reason, I get a lot of errors during the tagging process.
+//The code name/version number should have been bumped after the last delivery, so this should be OK.//
-=== Bad Gateway ===
+==== Commit Changes ====
-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:
+If needed:
-  $ svn info .
+  git commit -am "Updates for version xx.xx"
-  ...
+  git push
-  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.
+===== Release Day =====
-=== Password Prompts ===
+==== Create tarball ====
-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 related to trying to launch kwalletd.  It still seems to work.
+Finally, on the release date...
-=== Wallet? ===
+Download a snapshot from the [[https://sourceforge.net/p/rosegarden/git/ci/master/tree/|git repo page on SourceForge]].
-Any errors related to a "wallet" can safely be ignored and the wallet UI can safely be closed via the "cancel" button.
+cd to where the snapshot was saved and run the make-release-tarball script with the name of the snapshot:
-===== Test tarball =====
+  <path-to-source>/scripts/make-release-tarball <snapshot-name>.zip
+==== Test tarball ====
 Sanity test the tarball.  Build and run from it.
-===== Deliver =====
+==== Tag the Release ====
+From the sourcebase...
+  git tag -m "Release" xx.xx
+  git push --tags
+==== Deliver ====
+SourceForge
   - Create new version directory on sf
   - Upload the tarball to sf
-  - Upload the release notes to sf as README.  Wrap to 72 columns for email.
+  - Upload the current version section of the CHANGELOG to sf as README.
-  - 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 sourceforge to point to the new version.  Use the "i" icon to the right of the file.  Set "Default Download For:" to Tux.
+GitHub
-===== Update Website =====
+  * Create a release.
+  * Click on Releases in the right column.
+  * Click on "Draft New Release".
+  * README will need to be copied to the description field and reformatted to markdown.
+==== 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/getting/source/index.shtml (http://www.rosegardenmusic.com/getting/source/index.shtml)
+  * /website/index.shtml (https://www.rosegardenmusic.com/)
-    * Update link to the current stable release.
+    * Update version.
+    * Update link to release notes on wiki.
   * /website/subleft.html (main page on the left)
     * Add a new "newsheadline".
-  * /website/index.shtml (http://www.rosegardenmusic.com/)
+  * /website/getting/source/index.shtml (https://www.rosegardenmusic.com/getting/source/index.shtml)
-    * Update version.
+    * Update link to the current stable release.
-    * Copy in release notes summary.
-    * Update link to release notes on wiki.
-  * /website/latest-version.txt (http://www.rosegardenmusic.com/latest-version.txt)
+  * /website/latest-version.txt (https://www.rosegardenmusic.com/latest-version.txt)
     * Update version number.
@@ Line 169: / Line 240: @@
 Test, commit, wait for the auto upload (takes a while), and test.
-//See https://sourceforge.net/p/rosegarden/code/14701/ for an example.//
+  $ svn commit -m "Update website for xx.xx release"
+//See https://sourceforge.net/p/rosegarden/code/16159/ for an example.//
-===== Update CMakeLists.txt =====
+==== Update CMakeLists.txt ====
 Bump the version number and codename.
@@ Line 178: / Line 250: @@
 Commit.
+==== Announce ====
-===== Announce =====
   * user list
@@ Line 187: / Line 258: @@
   * etc...?
+===== Post-Release =====
-===== Point Release Process =====
+==== Clean Up Sourceforge ====
-//Discussion uses 17.12.1 as an example.//
+  * 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.
-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.
+===== Point Release Process =====
-  svn copy https://svn.code.sf.net/p/rosegarden/code/tags/rosegarden-17.12 \
+//Discussion uses 22.12.1 as an example.//
-           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.
+Create a new stable branch based on the tag you want to start at.
-  svn checkout --username=tedfelix \
+  git checkout -b 22.12-stable 22.12
-      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:
+Cherry-pick any commits you need from master.
-  svn merge -c 15189 ^/trunk/rosegarden
+Go back through the release process carefully.  Some things to watch out for:
-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].
+  - Start at [[dev:release_process#testing|Testing]].
+  - Update the CHANGELOG notes with a complete new point release.
-Finally, go back through the release process with the following changes:
-  - Start at [[dev:release_process#test_a_release_build|Test a Release Build]].
-  - Update the release notes with a new point release fixes section at the top.  E.g. "Fixes for 17.12.1".
   - Version will need to be adjusted in CMakeLists.txt.
+  - You will need to push the stable branch in order to generate a tarball.
   - No need for a new version directory on sf.
   - No need to bump the version number after the tarball.
 ===== See also =====