Update translation strings

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:
  1. $ lupdate src/src.pro
  2. $ git add src/translations/*.ts
  3. $ git commit
  • Notify the translators of the new strings + the tentative release date.

Update application version numbers (and commit + push the changes)

Create a new branch in git, based upon the new release version:

  1. $ git checkout -b v3.9.x

The x on the end as the minor version number is correct, as for branches all of the 3.9 series code will go into this same branch. eg 3.9.0, 3.9.1, etc.

In the new version branch

  1. Update the “CFBundleShortVersionString”, “CFBundleGetInfoString”, and “CFBundleVersion” strings in src/app.plist. Use the full version for these. eg 3.9.0
  2. In src/version.h, update the version number components as appropriate.
  3. In installer/windows/variables.wxi, update the version number components.

In the master branch

  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.9.99.
  2. In src/version.h, update the version number components as appropriate.
  3. In installer/windows/variables.wxi, update the version number components.

Build the application

  • Build the application package files, and add them to the draft Release
  • The .dmg file can also be signed, so do that too: $ codesign —sign “${DEV_ID}” —verbose —deep —keychain “/Library/Keychains/System.keychain” DB*.dmg
  • We really need to investigate making our own PortableApp version, instead of loading the work onto John Haller

Verify the version of SQLite being bundled

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

Build an AppImage version of the release

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

Add a good changelog

  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)

Publish the release

  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

Update website

  1. Update the download links
  2. Add a blog entry
  3. Add the new release to the releases section on the About page

Notify packagers

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

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

Updates stats counters

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

Notify people

  1. Update currentrelease file
  2. Email John Haller to let him know
  3. Send a tweet about it (retweet that from our personal accounts)
  4. Email SQLite Users [sqlite-users@mailinglists.sqlite.org](https://github.com/sqlitebrowser/sqlitebrowser/wiki/mailto:sqlite-users@mailinglists.sqlite.org)\ mailing list about the new release
  5. Update the MacOS X Homebrew formula, and the Homebrew Cask, for the new version
  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