Should charms have an equivalent of debian/watch?
clint at ubuntu.com
Wed Jun 27 16:40:20 UTC 2012
Excerpts from Mark Shuttleworth's message of 2012-06-27 06:35:17 -0700:
> 's a rather good idea, Jorge, as long as it's a config setting
> ("auto-update"). As a common pattern, one config could specify a source
> (stable package, ppa, version control) and another could specify whether
> to auto-update. So one could have a service "running tip" that
> auto-updated easily.
Right, I see the problem as similar, but not identical.
By default, a charm should deploy whatever upstream is recommending
people to put into production. If upgrades are simple and API's are kept
backward compatible, then upgrade-charm hooks should also move users
forward to whatever that upstream is.
Then we need only have a file in the charm root that defines what versions
are known to work. Something like watch.yaml:
known-working: [ '1.0.*', '2.0.*', '*daily*' ]
ignore: [ '0.*' ]
And for one that only has 1 version, just have it apply the pattern from
the url into a directory in the charm:
Then we can have the poller check two things.. 1: whether the default
version is behind upstream's newest releases, and 2: whether or not all
upstream releases are known to work.
This would all be straight forward work to get done. I think it belongs
in charm-tools, or perhaps jujucharms.com.
More information about the Juju