Skip to content

Commit

Permalink
Bumped version number.
Browse files Browse the repository at this point in the history
  • Loading branch information
ntoll committed Nov 6, 2016
1 parent 9bd4e71 commit c2a0f23
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 1 deletion.
5 changes: 5 additions & 0 deletions CHANGES.rst
Original file line number Diff line number Diff line change
@@ -1,6 +1,11 @@
Release History
===============

0.9.13
------

* Add ability to change default Python directory in the settings file. Thanks to Zander Brown for the contribution. See #179.

0.9.12
------

Expand Down
6 changes: 6 additions & 0 deletions debian/changelog
Original file line number Diff line number Diff line change
@@ -1,3 +1,9 @@
mu (0.9.13-1) unstable; urgency=low

* Add ability to change default Python directory in the settings file. Thanks to Zander Brown for the contribution. See #179.

-- Nicholas Tollervey <[email protected]> Sun, 06 Oct 2016 11:32:58 +0000

mu (0.9.12-1) unstable; urgency=low

* Change the default Python directory from ``~/python`` to ``~/mu_code``. This fixes issue #126.
Expand Down
2 changes: 1 addition & 1 deletion mu/__init__.py
Original file line number Diff line number Diff line change
@@ -1 +1 @@
__version__ = '0.9.12'
__version__ = '0.9.13'

4 comments on commit c2a0f23

@carlosperate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ntoll I think we should probably use a "prerelease" or "alpha" type of nomenclature to ensure we are able to differentiate between the CI builds uploaded to AWS and the proper releases.
It's not too bad for people downloading the bundled executables, as in case of doubt they could simple re-download the latest "proper release", but if somebody happens to use any of the http://ardublockly-builds.s3-website-us-west-2.amazonaws.com/?prefix=microbit/raspberry_pi/ deb files then they'll have issues updating the package.

@carlosperate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just realised there was a release with these, is the general idea to do a new release more or less with each PR or significant commit?

@ntoll
Copy link
Member Author

@ntoll ntoll commented on c2a0f23 Nov 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I believe releasing after a significant commit[s] is the way to go - but in this particular case I know there were several teachers waiting for this feature so wanted to get it out there ASAP since @ZanderBrown worked quickly to respond to a request for a change.

@carlosperate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, and I agree that it is better to release frequently, but there will always be small commits that might not trigger a "proper" release, and during that time there will be versions of Mu built by the CI servers with versions unrepresentative of their prerelease/alpha/interim status.
Just something to think about, I am not quite sure what are the immediate plans for 0.9.14, but having a "0.9.14a" tag until the proper release would avoid any issues on that respect.

Please sign in to comment.