For the schedule, years ago, we discovered that the odd months are best. So when the year starts and everyone comes back from holidays, we have a brand new release in mid January. This release increases the major version number. We have a x.0 release and people notice that something changed. Followed by releases over the year till November with last one. The individual releases are usually scheduled around conferences, e.g. the July release is what people get presented at FileMaker DevCon. Doing a release in October would be hard to manage due to conferences. In 2016 for example we visited Xojo Developer Conference, the German FileMaker conference and the Spanish FileMaker Conference. The October was quite full with not much office time left. Odd month numbers work great so far.
The cycle begins after a release. Usually there is a week or two where we can relax and enjoy watching people try the new release. There may be a few bug reports coming in and we may provide updated plugins to just the bug reporters to try. It's also a great time to start on something new for the next release, which may take several weeks to be finished.
The first prerelease usually comes out beginning of the next months (even number). People can enjoy the fixes we made and of course see a few first new features. Over the month we add more and publish a new prerelease about every week. Sometimes there is an update for DynaPDF. With some urgent fixes we may make an extra pr to push it out quickly.
For the release month (odd number), we pick a week for release. Usually trying to avoid a week with vacation, conferences or working on-site for a client. A week before the release we stop adding new features and just fix bugs. We check the new examples whether they work well on all platforms. Usually Sunday we start the checklist for the release to be made on Tuesday. The checklists are long and include a few points like rebuilding all plugins (Mac 32/64, Win 32/64, Linux 32/64 for Intel and Linux 32 for ARM) with proper code signing. We merge new examples with old examples. For Xojo we run our application to test build all examples (See earlier blog post). Than we run Arbed for all examples to create html versions. For FileMaker we run our tool to create the Database Design Reports and than the html for the website. We regenerate the documentation and make sure all new items are included. Next we create PDFs and upload the help files. The release notes file is cleaned up, sorted and links are added for the mentioned items. Monday we pack all the files into zip archives and digitally sign disk images. The upload takes a while as it's over 5 GB per release. Finally we upload new documentation files for Dash application.
On Tuesday we update the website to mention the new release, make blog articles and send emails to the mailing lists, our press list and put it on a few announce websites. Than we wait. A few minutes later some early adapter may have downloaded it, send congratulations or bug reports. And of course some people order updates for their licenses.
On the following Thursday we send a notice to everyone about the new release. The emails are personalized to display whether the license is current and it's a free update or whether a license key is expired and it may be a paid update. This leads to a few sales usually.
Now you know how much work a MBS release is. I suggest you try to approach something similar for your software with either years, half yearly, quarterly or even bi-monthly releases. Two things to note: A lot of customers only purchase if major version number increases, so we do that every year. We do a big portion of our sales with new release going out. But even more with renewal reminders sent on the first day of a month.
Finally all version numbers are arbitrarily chosen. All versions we upload can be used in production and we do that ourself for client projects. The only thing a beta version may have new code (not fully tested) and sometimes include debug messages being logged. But for our pr and final releases, we disable that.