It would seem to a humble outsider that project formalism and procedure is not the issue, instead that is expectations and impact on the outside world. We hear that branch-2 is approaching stability, except when it isn't, as evidenced by new downstream project unit test failures at each "minor" release, with major new features going in because it's too difficult to renumber. (??)
Would it work if a consensus can be found on renumbering upcoming 2.0.5 to 2.1.0? That would be a simple and effective concrete step toward resolving the disagreements I observe. Those who have voted +1 on this discussion+vote thread can stabilize 2.0.4, with additional fixes, RM a 2.0.x branch, describe it as stable, and meanwhile life goes on for everyone else on 2.1.x branch? Downstream projects could be advised to stick with 2.0.x for API and runtime stability until ready to make the leap up to 2.1.x or successor? On Sat, May 11, 2013 at 4:34 AM, Chris Douglas <cdoug...@apache.org> wrote: > It's unnecessary for you to ask permission to roll a release > containing (or omitting) the features you want. This vote is redundant > with the release vote; it's an unnecessary formalism in our bylaws. If > you want to release 2.0.5 with the features you want and assemble > other community members to help stabilize it in a 2.0.x series... > great. Do that. If the release vote passes and others want to add more > features, then they can roll a new series in 2.1. If the vote on your > artifact fails, then forward your "stability" agenda directly by > reviewing and contributing code. If a set of contributors wants to > support your agenda then they'll work on it, but if the developers > aren't there then neither is the project. > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
