On Tue, May 15, 2012 at 10:08 AM, Russ Teabeault <rteabea...@rallydev.com>wrote:
> I read the release process wiki page and at the risk of being flamed this > seems a bit heavyweight, especially when releasing patch releases. I am > not sure if I understand the need for voting and getting all the issues > down to zero. Would it be possible to have different release requirements > depending on the type of release (patch versus major)? > The vote is an Apache requirement. Any official release for any Apache project requires a vote, even patch releases. In practical terms, the vote gives everybody a period of 24-48 hours for testing releases which is probably a good idea regardless. Getting all the issues down to zero is based on what's been agreed to be fixed in a given release. If we're doing a patch release to fix something small, the list of issues could a single issue. In that respect, I wouldn't read the process too literally. It's meant as a guideline -- things to think about -- when doing a release. A committer fixes a couple of bugs and then: > > rake release - "Run specs, build gem, push to rubygems.com, done." > > It should be that simple. > Agreed in the sense that the process should be as automated as possible and involve the least amount of administrative overhead (while still abiding to Apache rules -- which again is just agreeing on what goes into a release and voting on the release packages when they're ready). > I am a big fan of buildr and I really want to see it thrive. I am willing > to volunteer my time to help do whatever is needed to get buildr to that > level of simplicity when releasing. > Great! Please try the rake scripts for staging/releasing and send back any suggestions/improvements you have. I would be thrilled to get back to a simpler/fully-automated release process. (I've done most of the recent releases and they have been too time-consuming). alex
