← Back to team overview

erma-core team mailing list archive

Re: ERMA Release Process

 

Releases 3.1 and 3.2 have now been tagged.


On Tue, Dec 16, 2008 at 12:21 PM, Doug Barth <dougbarth@xxxxxxxxx> 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
>
>

Follow ups

References