Mu: Sort out/formalise version handling

[tibs]

The mu version number is declared in mu/__init__.py. It appears to be a semantic version, which is good.

Things to think about:

• a released version of mu should correspond to a tag in the repository - i.e., before creating the binary distributions, tag the repository and use that tagged commit as their source
• there should be an appropriate entry in the CHANGES.rst file (this is a new file which is still on a branch at the moment, but will hopefully reach master soon). Note that when putting an entry into the CHANGES.rst file, the version title for that entry will be for the next release...
• preparing a new DEB will probably mean summarising more than one change from CHANGES.rst

Should we rely on people remembering all of this, or can some of it be scripted?

[ZanderBrown]

Possibly something for CONTRIBUTING file?

[ntoll]

+1 on CONTRIBUTING. PR's welcome. ;-)

[carlosperate]

Should we git-tag/github-release whatever current state we are right now as '0.9.11'? (or whatever commit the downloadable installers from the website have been created from)

[carlosperate]

@ntoll any thoughts on tagging/GH-releasing the current state as 0.9.11?

[ntoll]

Yes... but first "real work" is delivering a project today so will try to get to this this evening. (Have spent the last week or so running around like headless chicken for "real work" reasons).

[carlosperate]

No worries Nicholas, there is no rush, it was just a matter of agreeing on an initial gh-release before considering the merge of any other PR.

[carlosperate]

Taking in consideration the codewith.mu website had the download for 0.9.11 (including a copy of the source code) on this commit:
https://github.com/mu-editor/mu-editor.github.io/commit/acb36750b227cc4a54e010e3bab4df9aa9bf0446

I would suggest to retroactively create a git label and a github release for 0.9.11 from the correspondent commit from this repo: 328684e9646348e138477b92a6987e0aba929d90 .
(The windows executable was updated after the fact, but I don't think we should worry about tagging that)

If we do so, we should then add to the changelog any updates made after the 17th of July as part of v0.9.12.

[ntoll]

We have a changelog in the root of the repository, we do GitHub releases (and tag 'em). Closing.

Thanks for the feedback @tibs :-)