Differences

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

--- dev:release_process [2022/06/08 21:43]
tedfelix [Announce]
+++ dev:release_process [2025/12/03 15:59] (current)
tedfelix [Update Website]
@@ Line 4: / Line 4: @@
   - 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.
@@ Line 12: / Line 12: @@
 You can examine the commit history since the previous release in git using the command line:
-  $ git log --stat --reverse 21.06..master
+  $ 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).
@@ Line 26: / Line 27: @@
 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 46: / Line 70: @@
 Announce the string freeze/start of the translation period.
+==== Review 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..
+Run ts-untrans to find untranslated (blank translation) strings.
+  $ scripts/ts-untrans data/locale/de.ts
+Manually review and mark each untranslated string as unfinished as appropriate:
+  <translation type="unfinished">
+//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 =====
 On the eve of the release, send out a reminder for any last minute contributions and translations.
-===== Pending Changes =====
+==== 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 =====
+==== File Format Version ====
 Determine whether any changes have been made to the .rg file format.  The key routines are:
@@ Line 60: / Line 99: @@
   * ''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
+  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.
@@ Line 69: / Line 109: @@
 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.
-===== Update Copyright =====
+==== Turn Off Logging ====
-Before the June release...  Check for any single copyright years that need to be expanded to a range.  E.g. "Copyright 2020 ...".
+Search for any logging that is turned on and turn it off.
-  cd src
+  grep -rnl --include="*.cpp" "^//#define RG_NO" src
-  grep -rh --include="*" "Copyright .* Rosegarden development team" . | sort | uniq
-Fix those manually to include the current year.
+==== Testing ====
-From within the src directory, run the update-copyright script.
+  * 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:
-  ../scripts/update-copyright
+  $ grep Totals Testing/Temporary/LastTest.log
-Finally, commit the changes as Copyright Bot:
+  * Do a release build with tests turned on and run the tests.
-  git commit -a --author="Copyright Bot <copyright@rosegardenmusic.com>" -m "Update copyright"
+  $ mkdir build; cd build
+  $ cmake -DBUILD_TESTING=ON ..
+  $ make
+  $ make test
-===== Testing =====
+  * Do a regression test against the release build.
-On the release date...
+==== Finalize CHANGELOG ====
-  * From a debug build, do ''make test'' to run unit tests.
-  * Do a Release build and a regression test.
-===== Finalize CHANGELOG =====
   * Add any new changes to the CHANGELOG.
-  * Copy the latest version of the CHANGELOG to a new page [[:start#release_notes|on the wiki]].
+  * Copy the latest version of the CHANGELOG to the wiki.
-===== Turn Off Logging =====
+==== Update appdata ====
-Search for any logging that is turned on and turn it off.
-  grep -rnl --include="*.cpp" "^//#define RG_NO" src
-===== Update appdata =====
 Add release notes for the new release to the appdata file:
@@ Line 115: / Line 148: @@
   appstreamcli validate data/appdata/rosegarden.appdata.xml
-===== Update the README =====
+==== Update the README ====
 Update copyright year as needed.
@@ Line 121: / Line 154: @@
 Update anything else that seems like it needs updating.
-===== Update AboutDialog.cpp =====
+==== Update AboutDialog.cpp ====
-Update copyright year as needed.
+<del>Update copyright year as needed.</del>  (This is now set programmatically.  No change needed.)
+==== Update data.qrc ====
+Get the latest yoshimi.rgd file from https://github.com/lorenzosu/rosegarden_yoshimi_banks/
-===== Update data.qrc =====
+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 Code Name and Version =====
+==== Check Code Name and Version ====
 Check/adjust the code name/version number in CMakeLists.txt.
@@ Line 135: / Line 172: @@
 //The code name/version number should have been bumped after the last delivery, so this should be OK.//
-===== Commit Changes =====
+==== Commit Changes ====
 If needed:
@@ Line 142: / Line 179: @@
   git push
-===== Create tarball =====
+===== Release Day =====
+==== Create tarball ====
+Finally, on the release date...
 Download a snapshot from the [[https://sourceforge.net/p/rosegarden/git/ci/master/tree/|git repo page on SourceForge]].
@@ Line 150: / Line 191: @@
   <path-to-source>/scripts/make-release-tarball <snapshot-name>.zip
-===== Test tarball =====
+==== Test tarball ====
 Sanity test the tarball.  Build and run from it.
-===== Tag the Release =====
+==== Tag the Release ====
 From the sourcebase...
@@ Line 161: / Line 202: @@
   git push --tags
-===== Deliver =====
+==== Deliver ====
+SourceForge
   - Create new version directory on sf
   - Upload the tarball to sf
   - 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
+  * 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 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/index.shtml (http://www.rosegardenmusic.com/)
+  * /website/index.shtml (https://www.rosegardenmusic.com/)
     * Update version.
     * Update link to release notes on wiki.
@@ Line 179: / Line 229: @@
     * Add a new "newsheadline".
-  * /website/getting/source/index.shtml (http://www.rosegardenmusic.com/getting/source/index.shtml)
+  * /website/getting/source/index.shtml (https://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)
+  * /website/latest-version.txt (https://www.rosegardenmusic.com/latest-version.txt)
     * Update version number.
@@ Line 190: / 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 199: / Line 250: @@
 Commit.
+==== Announce ====
-===== Announce =====
   * user list
@@ Line 208: / Line 258: @@
   * etc...?
-===== Clean Up Sourceforge =====
+===== Post-Release =====
+==== Clean Up Sourceforge ====
   * 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.
 ===== Point Release Process =====
-//Discussion uses 21.06.1 as an example.//
+//Discussion uses 22.12.1 as an example.//
-Check out a "point" branch based on the tag you want to start at.
+Create a new stable branch based on the tag you want to start at.
-  git checkout -b point 21.06
+  git checkout -b 22.12-stable 22.12
-Cherry-pick any commits you need.
+Cherry-pick any commits you need from master.
-  git cherry-pick 9713720e
 Go back through the release process carefully.  Some things to watch out for:
@@ Line 231: / Line 282: @@
   - Update the CHANGELOG notes with a complete new point release.
   - Version will need to be adjusted in CMakeLists.txt.
-  - You will need to push the point branch in order to generate a tarball.  You can always delete it later.
+  - 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.
-Delete the point branch local and remote once the tags are pushed.
 ===== See also =====