Question for cosmetic and understandability of breadcrumbs in github

[Charles Butler]

Greetings,

I deposit many of my layers in GitHub, and one of the things  I've been
striving to do is keep tag releases at the revisions i cut a charm release
for a given channel. As we know, the default channel is seen by no-one, and
runs in increments of n+1.

My prior projects i've been following semver for releases, but that has
*nothing* in terms of a breadcrumb trail back to the store.

Would it be seen as good practice to tag releases - on the top most layer
of a charm - with what charm release its coordinated with?

Given the scenario that i'm ready to release swarm, and lets assume that to
date i haven't tagged any releases in the layer repository:

charm show cs:~containers/trusty/swarm revision-info
revision-info:
  Revisions:
  - cs:~containers/trusty/swarm-2
  - cs:~containers/trusty/swarm-1
  - cs:~containers/trusty/swarm-0

I see that i'm ready to push swarm-3 to the store:

git tag 3
git push origin --tags

I can now correlate the source revision to what i've put in my account on
the store, but this does not account for promulgation (which has an
orthogonal revision history), and mis-match of those id's.

I think this can simply be documented that tags track
<<username>>/<<charm>> pushes, and to correlate source with release, to use
the method shown above to fetch release info.

Does this sound useful/helpful or am I being pedantic? (I say this because
Kubernetes touches ~ 7 layers, and it gets confusing keeping everything up
to date locally while testing, and then again re-testing with
--no-local-layers to ensure our repositories are caught up with current
development work. (Cant count the number of open pull requests hanging
waiting for review because we've moved to the next hot-ticket item)

All the best,

Charles
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160616/4bf5ed60/attachment.html>