Releases 3.1 and 3.2 have now been tagged.
On Tue, Dec 16, 2008 at 12:21 PM, Doug Barth <[email protected]> wrote: > 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 : [email protected] Unsubscribe : https://launchpad.net/~erma-core More help : https://help.launchpad.net/ListHelp
