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
_______________________________________________
Mailing list: https://launchpad.net/~erma-core
Post to : erma-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~erma-core
More help : https://help.launchpad.net/ListHelp
