erma-core team mailing list archive

[Doug Barth <dougbarth@xxxxxxxxx>]

On Dec 15, 2008, at 1:17 PM, Matthew Kemp wrote:
> Since we're getting ready to do our second release from github, I  
> figured that it was a good time to look at our release/review  
> process. Per our previous discussion features will be promoted to a  
> feature stream (not master) on your github repo. Once a feature is  
> reviewed it can be merged into master for the next release. I was  
> looking at git-tag to create a "version x" that someone could  
> checkout. The idea being whenever we cut binaries we'd also tag the  
> current commit with "Version X.Y". Does this sound acceptable?

This approach sounds pretty reasonable. I'd suggest publishing  
branches named after the issue you are fixing (eg. fixes/ERMA-42).

Tagging the release should definitely be done. We should also make  
sure that that tag is digitally signed.

  git tag -s 3.2

Also, not sure if you guys are following the Github blog, but they  
just pushed out some changes today to make reviewing pending changes  
easier through the web.

   http://github.com/blog/270-the-fork-queue

Also, the github Rubygem adds a command line utility that makes  
working with github repositories a little easier.

  sudo gem install defunkt-github
  github -h

--
Doug Barth