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 minor 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