Semver instead of revisions for charms?

[Stuart Bishop]

On 28 February 2016 at 19:49, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> There is no plan at this time to move to anything other than revision
> numbers for charm. The idea behind the system is there should really /never/
> be any backwards compatible breaks. If you find yourself running into a
> situation, make use of the upgrade-charm hook to update/rewrite any internal
> data structures you're using to the new version.
>
> This way charms are always forward looking and up-gradable as such. While
> I'm a huge fan of semver, adding that as a primitive for charms means there
> may be chances where a user of a charm won't be able to upgrade. That's a
> precedence we don't want to set.

I'm not sure how semantic versioning would make the situation any
different. I can introduce a backwards incompatible change just as
easily between cs:foo/99 and cs:foo/100 as I can between v3.9.4 and
v4.0.0. For what its worth, I'm switching to semantic version numbers
in my branches via tags in order to properly document changes and
tested upgrade paths. This is decoupled from the charm store
revisions, as several stable releases can be made before it gets
synced into the charm store.

I believe backwards compatibility issues are impossible to avoid
completely. Sometimes they are necessary, sometimes they are
accidental, and reverting landed revisions very dangerous as it
introduces a completely untested upgrade path for deploys made from
the reverted version (it might be weeks before a backwards
incompatible change is found). While we can all do our best,
occasionally it has to happen and all we can do is make things as
clear as possible to users.

I find versioning is a common issue, particularly regarding upgrades.
It seems more common than not that people are deploying from branches
rather than the charm store (either for bug fixes, requested features,
or lack of egress). I hope the version tags, git commit ids and maybe
a version.yaml will make these deploys much easier to deal with. I was
thinking a version.yaml convention would be good for composed charms,
as charm-build could merge them and we get tracking of which versions
of what layers got used in a particular build. And layers don't get
charm store revision ids. Once we have version numbers, we can do
proper bug tracking and milestones etc. on all these components that
can be used to build a charm. Machine readable, so the charm store
could display it and we could tell at a glance which charms need
rebuilding because they embed buggy or insecure layers.

-- 
Stuart Bishop <stuart.bishop at canonical.com>