Funkwhale
/
Clementine-audio-player-Mac-Linux-Windows
mirror of https://github.com/clementine-player/Clementine
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated Releasing a new version of Clementine (markdown)

John Maguire 2020-04-11 22:21:13 +01:00
parent 96e637d885
commit de46fce2af
1 changed files with 13 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
Releasing-a-new-version-of-Clementine.md

@ -8,18 +8,9 @@ It's usually best to make a release candidate about 1 week before the final rele
- Update the Changelog file by looking at the git log from the time of the last release. Make sure you don't include commits that were made in master during the last release cycle and cherry-picked into a release.
- Create a git branch for the release:
git checkout -b release-1.1
All development should still happen in the master branch, and any commits that need to go into the release should be cherry-picked from master into the release branch:
git cherry-pick -x [revision]
- Bump the version number of the branch. Edit the `cmake/Version.cmake` file and:
- Bump the version number. Edit the `cmake/Version.cmake` file and:
- Change the `CLEMENTINE_VERSION_MAJOR` and `CLEMENTINE_VERSION_MINOR` variables to match the version number.
- Uncomment `CLEMENTINE_VERSION_PRERELEASE`.
- Set `INCLUDE_GIT_REVISION` to `OFF`.
For example:
@ -28,27 +19,14 @@ It's usually best to make a release candidate about 1 week before the final rele
set(CLEMENTINE_VERSION_MINOR 1)
set(CLEMENTINE_VERSION_PATCH 0)
set(CLEMENTINE_VERSION_PRERELEASE rc1)
# This should be set to OFF in a release branch
#set(INCLUDE_GIT_REVISION ON)
Commit this change. The commit will be merged back into trunk after the release is complete. Push the new branch to the repository with:
Commit this change.
git push -u origin release-1.1
- Tag the release, e.g., `git tag 1.1.0-rc1 -a 'Clementine 1.1.0 RC1'`
- Build the binaries. Go to the [builders page on buildbot](http://buildbot.clementine-player.org/builders) and scroll down to the `Force Selected Builds` section:
- Push the tag `git push origin 1.1.0-rc1`
- Select the Deb and Rpm builders that you want to target. As a rule of thumb, we target the two most recent Fedora versions, all Ubuntu versions since the last LTS release, and Debian Squeeze.
- Select the MinGW-w64 Release builder and the Mac Release builder.
- Enter your username and password.
- In `Branch to build` enter the branch name that you created earlier (`release-1.1`).
- Click `Force build`.
Monitor the build on [the grid page](http://buildbot.clementine-player.org/grid). It will take 1-3 hours to build everything, depending on how many other builds were queued at the time.
- Gather all the binary and source packages together into one directory on your local machine. Buildbot will put the binary packages you told it to build into http://builds.clementine-player.org/
- [Create a new release on github](https://github.com/clementine-player/Clementine/releases/new) and upload all the packages you downloaded before.
- Wait for binaries to be built by CircleCI and pushed as a Github release.
- Send an email to the mailing list to announce the release candidate. You should include a short summary of the major features and link readers to the full changelog and the downloads page. For example: https://groups.google.com/forum/?fromgroups=#!topic/clementine-player/3jPLPYKVuAU
@ -58,15 +36,13 @@ It's usually best to make a release candidate about 1 week before the final rele
## During the release candidate phase
- If any major bugs are found (or you have a new idea for nyanalyzer cat), make commits to master and then cherry-pick them across to the branch by:
git cherry-pick -x [revision]
- If any major bugs are found (or you have a new idea for nyanalyzer cat), make commits to master and then tag a new release.
## Final release
- At the end of the release candidate phase you should update the Changelog file with any changes that were done in master and then cherry-picked into the release branch. You should make this change to the Changelog in master and then cherry-pick it across, just like a normal bugfix.
- At the end of the release candidate phase you should update the Changelog file with any changes that were done.
- Bump the version number of the branch. Edit the `cmake/Version.cmake` file and:
- Bump the version number. Edit the `cmake/Version.cmake` file and:
- Comment out `CLEMENTINE_VERSION_PRERELEASE`.
For example:
@ -76,13 +52,12 @@ It's usually best to make a release candidate about 1 week before the final rele
set(CLEMENTINE_VERSION_MINOR 1)
set(CLEMENTINE_VERSION_PATCH 0)
# set(CLEMENTINE_VERSION_PRERELEASE rc1)
# This should be set to OFF in a release branch
#set(INCLUDE_GIT_REVISION ON)
Commit this change to the release branch (don't put it in master yet).
Commit this change to `master`.
- Build the binaries and the source tarball exactly the same as you did for the RC.
- Tag (e.g, 1.4.1) and push as before.
- Let the binaries build and push like before.
- While everything is building you can take 4 screenshots that demonstrate some of the new features in the new release. I try to make sure we have screenshots of each platform (Windows, OS X and Linux). Once you've taken 4 screenshots:
- Make sure you've checked out the `appengine` repository ([instructions](http://code.google.com/p/clementine-player/source/checkout?repo=appengine)) and installed the [appengine SDK for Python](https://developers.google.com/appengine/downloads).
@ -106,7 +81,6 @@ It's usually best to make a release candidate about 1 week before the final rele
- Update the `www.clementine-player.org/data.py` file in the appengine repository with information about the new release:
- Update the `LATEST_VERSION` constant.
- Add a new dictionary to the `SCREENSHOTS` array.
- Add new entries to the `DOWNLOADS` array, one for each package we're building this time.
- If we've added a new Ubuntu or Fedora type, add it to `DISPLAY_OS`, `SHORT_DISPLAY_OS` and `OS_LOGOS`.
- Write a short paragraph describing the new stuff in the release and add it to the end of `NEWS`. Be sure to take today's timestamp by running:
@ -120,55 +94,7 @@ It's usually best to make a release candidate about 1 week before the final rele
And then going to http://localhost:8080/ in a web browser.
- If everything looks good commit these changes to the appengine repository, but don't push to the live appengine site until everything else is done.
- Gather all the binaries together in a directory on your local machine and upload it to Google Code just as you did for the RC.
- Go to the downloads page on Google Code and mark all the old downloads as Deprecated. This includes the last stable version as well as the release candidate you uploaded a week ago.
- Give the newly uploaded files the Featured label so they show up on the home page.
- [Update the Google Code project summary](http://code.google.com/p/clementine-player/admin):
- Move the old news to the old news section and insert the news for this release. If you copy and paste the news you wrote for the website remember to convert any links into wiki markup style.
- Update the screenshot URLs.
- Add any new features to the list at the top.
There's no way to preview this summary before you save, and it's not version controlled, so be careful.
- Deploy the website to appengine:
- Update the `version` field in the `app.yaml` file to match the number of this release. Using a new app version number like this lets us test and maybe rollback this version of the website using Appengine.
- Push this version of the website by running:
appcfg.py update .
Test that this looks good by going to the special versioned appspot URL http://release-1-1.clementine-web.appspot.com/ (change the 1-1 part).
- Make this new version the default by going to the Versions tab on https://appengine.google.com/
- Don't forget to commit the change to the `app.yaml` file.
- Tag the release branch in git. Be sure to tag the exact revision that you released:
git checkout release-1.1
git tag -s 1.1
git push --tags
Sign the tag with a GPG key that's associated with you in Launchpad.
- Merge the release branch back into master.
git checkout master
git merge release-1.1
Also make a new commit in master to change `cmake/Version.cmake` and enable `INCLUDE_GIT_REVISION` again.
- Upload packages to the stable PPA.
cd dist
./uploadtoppa.sh tags/1.1 lucid
./uploadtoppa.sh tags/1.1 maverick
...
You'll need to do this once for each of the PPAs.
- If everything looks good commit these changes to the `Website` repository and push to `master`.
- Sign the release for Sparkle