> Should we create a document for the website that we vote on? I think > you've captured most of what we need now in this email, but it would > be a good start for the bylaws when we get back to them.
I was following the sequence Doug suggested in the last thread on the release process. I can draft a vote if no discussion of this is necessary. >> In the short to medium term, all releases would come off of trunk. > > Wouldn't this prohibit a point 0.21 release? Do we want to do this? Sorry, I meant minor releases. I assumed patch releases per (3.ii) and (3.iii). The rules seem to allow an RM to cut releases from branches as well as trunk, so I was trying to avoid the confusing prospect of releasing, for example, 0.22 from the 0.21 branch instead of from trunk (unless the odd/even release convention were adopted). >> If >> a self-nominated RM for 0.x does not release before 0.y is ready, then >> 0.y is released as 0.x, the 0.x branch is retired, and the RM for 0.x >> needs to be reelected to release 0.z (where x < y < z). Does this make >> sense? > > I agree with the sentiment, but in practice it might be confusing to > release 0.y as 0.x - I worry about getting JIRA issues marked as being > fixed in 0.x not 0.y, and in general updating all the references to > 0.y (including branches). How about just skipping the 0.x version? I meant to describe what's happening with 0.21, more or less. Given requirement (3.i), nothing should be in (unreleased) 0.x that isn't also in trunk. If 0.x has a complex/buggy feature that's preventing it from being released, allowing someone to RM a release without it and call that 0.x, pushing the feature to 0.y is messy, but not as confusing (given Hadoop's deprecation and interface stability guarantees). It's also a merciful way to kill a stuck release without indicting the struggling RM. -C
