0.7.0

0.7.0 release highlights:

• opt-in to test controller-side state via Juju 2.8's state-get/state-set (#317, #323)
• support for running on Juju pre-2.7 (#324)
• exceptions now logged via an ad-hoc excepthook (#322)
• performance improvement for large yaml blobs (#325)
• bug fixes :-)

0.6.1

• Fix a regression when running a non-dispatch-enabled charm on a dispatch-aware juju.
• Also a fix for status-get, which isn't a regression but has been deemed safe for a .1.

0.6.0

This is the first “official” release, and includes a few breaking changes from what was in master until very recently. From now on, breaking changes will be announced, and we’ll have a deprecation procedure to ease things in (or rather, out). These breaking changes are:

• The Framework object’s observe method’s second argument can no longer be an instance, and must be a method on an instance. That is, where previously you could write

  self.framework.observe(self.on.install, self)

  as a shortcut, but we found that this pushes people down a path that actually makes their charms less maintainable. Especially when it comes to writing components, it is better to have clearly named functions and clearly defined targets.

  So from now on the only supported way is to explicitly specify the callback method,

  self.framework.observe(self.on.install, self._on_install)

  (note we also recommend event handlers to be clearly marked as non-public).

• Relations' role attribute is now an enum, and in particular peer relation's role is now "peer" (it used to be "peers" which was just wrong).

This release includes full support for Juju 2.8's dispatch mechanism,including both use cases of dispatch being a symlink to the charm code, and dispatch being a small shim that executes the charm. The latter is an incremental improvement over what we mentioned in the last dev summary, and is already being used by charmcraft.

Lastly, Model objects now have a name property (populated from JUJU_MODEL_NAME). This was a feature requested by charmers.