To improve the release cycle of the service, we will adopt the popular Gitflow workflow, as described by Vincent Driessen, across all Brown Dog services and clients:
http://nvie.com/posts/a-successful-git-branching-model/
Atlassian also recommends this workflow and provides slightly different description (along with a few other workflows):
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow
Tags will be the of the format "v0.2.1" and should be consistent across all git repositories. Tags should only be created on the commit in the master branch. So the release branch will first have to merged into master and then master will be tagged.
Development machines should follow the develop branch of each repository and be auto-deployed.
Deployment on production machines will only happen once a version has been tagged.
For software that follows it's own release cycle (for example Clowder), a release of that software should be tagged according to the specific project. If possible, a brown dog tag could be added to that repository, but it should point to the same commit as the project specific tag. For example, Brown Dog v0.2.0 will use Clowder v1.3.0. A tag of the form "browndog_v0.2.0" could be added to the Clowder repository.
A changelog will be kept for a high level overview of the changes. Ideally each repository should keep its own changelog.