Patch/Minor Release Process

Patch release

Patch releases contain changes which:

  • Don't introduce translatable strings changes
  • Don't change the user interface
  • Don't implement feature requests involving usability
  • Each change which is intended to be a part of the patch release should contain related mtest, vtest or script test if possible
  • Changes related to Plugin API which do not change the existing functionality. The changes introducing new fields or properties to the Plugin API may be a part of Patch Release. The changes affecting existing API should be thoroughly tested and become a part of a Minor Release.

What should be done before release:

  • Each change should be tested manually
  • The patch release branch is always based on the previous patch release branch or minor release
  • The changes are cherrypicked from master branch according to the rules described above
  • All changes (that don't fix found regressions) should be tested at least for three days
  • before the release date.

Minor release

What changes go to a patch release:

A minor release is built on top of the master branch and contains all the changes, except:

  • The changes in UI/UX which significantly change accustomed user workflows
  • File format changes which lead to a complete incompatibility with previous versions of MuseScore

What should be done before release:

  • All changes (that don't fix found regressions) should be tested for at least one week
  • before the release date

  • Each minor release update should be preceded by Beta and Release Candidate packages which are available for the community
  • Beta version should be prepared and publicly shared at least three weeks before the scheduled Minor Release date
  • Once Beta version is out, feature freeze happens, which means no changes related to the user interface or changing current functionality will be merged
  • Release Candidate should be prepared at least one week before the scheduled Minor Release date
  • After Release Candidate is out, no changes will be accepted except those fixing the regressions found comparing to the latest patch release
  • String freeze happens at the time of publishing Release Candidate. No new strings or string changes will be merged
  • The announcement for the translators including an ETA of the final release should be published within a day after publishing Release Candidate
  • Once the Release Candidate is out, no more strings will be pushed to Transifex

Release Timeline

We decided to try time-based releases inspired by Martin Michlmayr's publication and the experience of Debian, Linux, Gnome, and OpenOffice projects.

Releases Timeline

MuseScore 3.2.4 13.08.2019
MuseScore 3.2.5 27.08.2019
MuseScore 3.3 Beta 03.09.2019
MuseScore 3.3 Release Candidate 17.09.2019
MuseScore 3.3 24.09.2019
MuseScore 3.3.1 08.10.2019