Let us show you 10 steps on what to think about for professional software releases:

• Release often

  Do frequent smaller releases, so you can better train your releases.
  If you do it once a year, you forget all the steps and miss some.

• Plan your releases. When do you intent to release?

  Start the process a week before, at least to be sure you are ready.
  You may prefer to targeting specific weeks, where you have no family event planned or vacation.
  Or release a week before a conference, so the release is out and you can present it.

• Write down all steps needed.

  Setup a list of things you do for a release. That may start a week before with drafting announcement texts.
  Your list needs to include what files to update (readme files), what things to copy where, how to build, code sign, package, notarize and upload the app.
  It is very easy to miss an important step early and then you have to redo a lot of steps.
  Try the steps on another computer for a training release, so you can make sure nothing is missing or depends on an application installed on the computer.
  Always great if multiple people could do the job on multiple computers.

• Avoid trouble

  Don't install major software updates before release.
  We have automatic updates stopped to avoid Apple pushing us a new Xcode version (or Microsoft a new Visual Studio version). We can do the update after a release on the beginning on a development cycle.
  Same for new version of Windows, macOS or linux distribution.
  Check the expiration dates of your certificates. It would be bad if your code signing or website SSL certificate expire in the next weeks. Renew them now, before you discover that in the release week.

• Prepare announcements and release notes a couple of days before release.

  For example write a draft a week before. Wait a few days and then improve it three days before release.
  Read again on release date to look for typos. Better have someone else read it.
  Your brain caches the text and you may read what you think is there, but not the actual letters.

• Don't chase the last bugs.

  If you get bug reports the days before release on last beta versions, you may need to decide between various routes:

  • Fix it right now and include in release.
    Big caveat is that you may introduce a big bug fixing a small one!
  • Fix for the affected user and make an alternate build for them, e.g. from a branch in your source code repository. Everyone else gets it with a .1 release later.
  • Delay the release a week or two to fix an important bug.
  • Fix it for next release and ship a version, which may have known issues affecting hopefully only a small set of people.

  Eventually you will always ship with a few known issues as you have to ship someday and can't delay forever.

• Upload a day earlier.

  Nothing is worse than a server or bandwidth problem with uploading the day of release.
  I usually try to get things done before release day, so on release day I ned to upload last changes to website and send out announcement emails and forum posts.
  Go to different computer, download your release, install and check that it works.
  Avoid shipping a broken version (e.g. code signing broken) to thousands of customers.

• Test in-app updates

  If you have in-app update, take the new app, change it's version info to the older version and have it update itself to see whether new version can do the in-app update and whether it installs the new one. You may need a test xml file on server for that and point to the test URL.

• Script processes as much as possible.

  Have shell scripts ready to do various works including tests. That may reduce the number of steps to do above.
  For example scripts to pack release complain if the version to pack is not from the same day, has too small file size or has files missing. Scripts to package disk images for Mac can code sign them, check size and alert you if something doesn't work as intended.
  The notarize scripts will do notarizing and then check if the file is notarized on the end by asking spctl command line tool.

• Use tiers for release

  Post the last beta three days before may be the final release version.
  That allows your beta testers to install the version earlier and check for fatal errors in packaging.
  It trains tools like Windows SmartScreen to recognize the new installer. Windows may show users that an installer has no reputation, but if you can get a 1000 installations from your users quickly, the warning may go away.
  If you like, run your installer with tools like virus total and report false positive if it hits you.
  Keep days between release on website, announcements and newsletters, so you have time to react if something is broken.
  For example, get <1% of users with last beta, get a few percent with release day on website, get a few more after sending out announcements. But when you send newsletters to clients a day later, you may half of your users to install it within a few days. If you have a problem, the tiered system lets you stop, fix an issue and then have people get a fixed download.

We learnt a lot of lessons above the hard way. Did we miss something?