Should charms have an equivalent of debian/watch?

[Clint Byrum]

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:

url: "http://foo/downloads"
pattern: "foo-(*.).tar.gz"
default:
    source: config
    field: upstream-version
versions:
    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:

url: "http://bar/downloads"
pattern: "bar-(*.).tar.gz"
default:
    dir: "files"

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.