Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:release_process [2019/06/13 17:13]
tedfelix [Update the README]
dev:release_process [2023/12/06 12:58] (current)
tedfelix [Deliver]
Line 1: Line 1:
 ====== Release Process ====== ====== Release Process ======
- 
  
 ===== Plan the Release ===== ===== Plan the Release =====
Line 6: Line 5:
   - Pick a release date.   - Pick a release date.
   - Schedule a string freeze and translation period prior.  One week is fine.   - Schedule a string freeze and translation period prior.  One week is fine.
 +  - Schedule a testing (feature freeze) period.  Four weeks is good.
   - Announce the schedule.   - 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...
 +
 +  * 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.
 +  * Run the unit tests with ''make test''.
 +  * Perform a regression test.
  
 ===== String Freeze ===== ===== String Freeze =====
Line 17: Line 42:
 Commit this: Commit this:
  
-  $ svn commit -"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. Announce the string freeze/start of the translation period.
Line 24: Line 50:
  
 On the eve of the release, send out a reminder for any last minute contributions and translations. 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. 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.  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.+Determine whether any changes have been made to the .rg file format.  The key routines are:
  
-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.+  * ''RosegardenDocument::saveDocument()'' 
 +  * ''RoseXmlHandler::startElement()'' (and others in ''RoseXmlHandler''
 +  * ''Composition::toXmlString()'' (and other toXmlString() routines throughout the system)
  
 +Git should ferret out the changes:
  
-===== Test a Release Build =====+  git log -p -w src/document/RoseXmlHandler.cpp src/document/RosegardenDocument.cpp src/base/Composition.cpp
  
-On the release datedo a couple of Release builds and a few sanity checks to make sure nothing is broken.+If changes have been made to the file formatdecide 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 Release Notes =====+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.
  
-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.)+===== Update Copyright =====
  
-In a working copy, do an svn log to see the log entries from the previous release to the latest.+Before the June release...  Check for any single copyright years that need to be expanded to a range.  E.g. "Copyright 2020 ...".
  
-  $ svn log --r 13662:HEAD less+  cd src 
 +  grep -rh --include="*" "Copyright .* Rosegarden development team" . | sort uniq
  
-//An alternative would be to browse the commits on sourceforge I find it cumbersome, however.//+Fix those manually to include the current year.
  
-Update the release notes to reflect the commits since the last release.+From within the src directory, run the update-copyright script.
  
-  http://www.rosegardenmusic.com/wiki/dev:next_version+  ../scripts/update-copyright
  
-When finishedmove the release notes from the "Upcoming Release" page on the wiki to an official versioned release notes page on the wiki.+Finallycommit the changes as Copyright Bot:
  
-//Consider including the release notes within the tarball in the future.  Maybe just accumulate them in single file What do other projects do?  Changelog!//+  git commit ---author="Copyright Bot <copyright@rosegardenmusic.com>" -m "Update copyright"
  
 +===== Testing =====
  
-===== Update the README =====+On the release date...
  
-Update copyright year as needed.+  * 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 anything else that seems like it needs updating.+<file> 
 +$ grep Totals Testing/Temporary/LastTest.log 
 +</file>
  
-===== Update AboutDialog.cpp =====+  * Do a Release build and a regression test.
  
-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.+===== Turn Off Logging =====
  
 +Search for any logging that is turned on and turn it off.
  
-===== Check Code Name and Version =====+  grep -rnl --include="*.cpp" "^//#define RG_NO" src 
 +===== Update appdata =====
  
-Check/adjust the code name/version number in CMakeLists.txt.+Add release notes for the new release to the appdata file:
  
-//The code name/version number will be bumped after delivery, so this should be OK.//+  data/appdata/rosegarden.appdata.xml
  
 +Also update the copyright year at the top.
  
-===== Commit Changes =====+Validate with appstreamcli:
  
-If needed:+  appstreamcli validate data/appdata/rosegarden.appdata.xml
  
-  svn commit -m "Updates for version xx.xx"+===== Update the README =====
  
 +Update copyright year as needed.
  
-===== Create tarball =====+Update anything else that seems like it needs updating.
  
-Use the make-release-tarball script:+===== Update AboutDialog.cpp =====
  
-  scripts/make-release-tarball RELEASE +Update copyright year as needed.
-   +
-==== Tagging the Release ====+
  
-The make-release-tarball script will tag the release from trunk.  This is correct for non-point releases.+===== Update data.qrc =====
  
-For point releases, we need to tag the release from the stable branch:+Get the latest yoshimi.rgd file from https://github.com/lorenzosu/rosegarden_yoshimi_banks/
  
-  svn copy svn+ssh://tedfelix@svn.code.sf.net/p/rosegarden/code/branches/stable-17.12 \ +Copy it to data/library and make sure it is all lower-case "yoshimi.rgdto match the previous 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.// +Run "scripts/rebuild-qrc-nosvn" to make sure the data.qrc file is up-to-date.
-==== Tagging Errors ====+
  
-For some reason, I get a lot of errors during the tagging process.+===== Check Code Name and Version =====
  
-=== Bad Gateway ===+Check/adjust the code name/version number in CMakeLists.txt.
  
-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:+//The code name/version number should have been bumped after the last delivery, so this should be OK.//
  
-  $ svn info . +===== Commit Changes =====
-  ... +
-  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.+If needed:
  
-=== Password Prompts ===+  git commit -am "Updates for version xx.xx" 
 +  git push
  
-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.  It still seems to work.+===== Create tarball =====
  
-=== 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: 
 + 
 +  <path-to-source>/scripts/make-release-tarball <snapshot-name>.zip
  
 ===== Test tarball ===== ===== Test tarball =====
  
 Sanity test the tarball.  Build and run from it. 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 ===== ===== Deliver =====
Line 140: Line 177:
   - Create new version directory on sf   - Create new version directory on sf
   - Upload the tarball to 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.
  
 ===== Update Website ===== ===== Update Website =====
Line 148: Line 184:
 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. 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 (http://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)   * /website/subleft.html (main page on the left)
     * Add a new "newsheadline".     * Add a new "newsheadline".
  
-  * /website/index.shtml (http://www.rosegardenmusic.com/) +  * /website/getting/source/index.shtml (http://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 (http://www.rosegardenmusic.com/latest-version.txt)
Line 185: Line 220:
   * etc...?   * etc...?
  
 +===== Clean Up Sourceforge =====
 +
 +  * Bugs: Go through all "feedback" and close.
 +  * Feature Requests: Go through all "feedback" and close.
 +  * Close any merge requests that were accepted.
  
 ===== Point Release Process ===== ===== Point Release Process =====
  
-//Discussion uses 17.12.1 as an example.//+//Discussion uses 22.12.1 as an example.//
  
-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.+Create new stable branch based on the tag you want to start at.
  
-  svn copy https://svn.code.sf.net/p/rosegarden/code/tags/rosegarden-17.12 +  git checkout -b 22.12-stable 22.12
-           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.+Cherry-pick any commits you need from master.
  
-  svn checkout --username=tedfelix \ +Go back through the release process carefully.  Some things to watch out for:
-      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: +  - Start at [[dev:release_process#testing|Testing]]. 
- +  - Update the CHANGELOG notes with a complete new point release.
-  svn merge -c 15189 ^/trunk/rosegarden +
- +
-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]. +
- +
-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.   - 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 for a new version directory on sf.
   - No need to bump the version number after the tarball.   - No need to bump the version number after the tarball.
- 
  
 ===== See also ===== ===== See also =====
 
 
dev/release_process.1560445996.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