Try to do this step a few days before the release, so translators have time!

• Update the .ts files under src/translations, then commit them to the master branch:

$ lupdate src/*.cpp src/*.ui src/*.h -ts src/translations/*.ts
$ git add src/translations/*.ts
$ git commit

• Notify the translators of the new strings + the tentative release date.

If the new release is the first one (e.g. v3.50.0) in a new series (e.g. v3.50.x), then create a new branch in git (based on master) for the new release series:

$ git checkout master
$ git checkout -b v3.50.x

The x on the end as the minor version number is correct there, as for branches all of the 3.50 series code will go into this same branch. eg 3.50.0, 3.50.1, etc.

1. Update the "CFBundleShortVersionString", "CFBundleGetInfoString", and "CFBundleVersion" strings in src/app.plist. Use the full version for these. eg 3.50.0
2. In CMakeLists.txt, update the VERSION number components as appropriate.
3. In installer/windows/variables.wxi, update the version number components.

1. Update the "CFBundleShortVersionString" and "CFBundleVersion" version strings in src/app.plist. The new version string needs to be the latest release number + .99 on the end. eg if the new release is for version 3.9, then the master branch version of this string will be 3.50.99.
2. In CMakeLists.txt, update the VERSION number components as appropriate.
3. In installer/windows/variables.wxi, update the version number components.

• Verify it works with a new (minimal) install on (say) CentOS 7 x64

• The .dmg file should be automatically signed by our build script. If that doesn't work for some reason, it can be done manually with: $ codesign --sign "${DEV_ID}" --verbose --deep --keychain "/Library/Keychains/System.keychain" DB*.dmg

• The windows binaries need to be manually signed with our certificate. Martin does that, so upload the binaries to our nightly server and let him know:

  • https://nightlies.sqlitebrowser.org/win32-prerelease/
  • https://nightlies.sqlitebrowser.org/win64-prerelease/

• @chrisjlocke has been working on making our own PortableApp version, too

• Install the new OSX .app from the .dmg, start it, and check the SQLCipher version in the About dialog. If this isn't at least 3.41.0 then something has gone wrong and needs to be fixed.

1. Use the Milestone "closed issues" thing for the initial text
2. Then add links and make the text nicer sounding (where possible and not too difficult)

1. Make sure we have both the Windows and OSX packages on there first
2. Add the new release info to the History section of the source repo README.md, and the about page of the website
3. Update the version numbers in the issue reporting template

• It's the sqlitebrowser/website repo.
  • Uses Hugo and blogdown

1. Update the download links
2. Add a blog entry
3. Add the new release to the releases section on the About page
4. Add the same entry to the front page of the GitHub repo readme

Email, or ping via GitHub, our packagers to let them know about the new release:

• deepsidhu1313 (Ubuntu)
• @lbartoletti (FreeBSD)
• Arch?
• Gentoo?
• RHEL/Fedora?

1. Create cronjob scripts to get the daily download count for the new release binaries from GitHub

[Note from Justin - Heh, I'm not sure if this is even still running. Should look into that. 😉]

1. Update currentrelease file
   • In the master branch of our GitHub repo
   • On our download server cluster
2. Email John Haller to let him know
3. Send a tweet about it (retweet that from our personal accounts)
4. Announce the new release on the SQLite Users Forum: https://sqlite.org/forum/forum
   • @chrisjlocke is active on that forum, so might be the right person to do this
5. Update the MacOS X Homebrew formula, and the Homebrew Cask, for the new version
   • Homebrew Casks is well maintained by the community, but is generally handled by @lucydodo
6. Add a mention of the new release on the SQLCipher forums
7. Do a "News" item release on our SourceForge page (but don't upload the files there)
8. Let the maintainers of the Chocolatey package know
   • Do we need to do anything for the WinGet repo?