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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
