Konstantin Shvachko wrote:
I would like to propose a straightforward release of 0.21 from current
0.21 branch.
That could be done too. Tom's volunteered to drive a release from trunk
in a few weeks. Owen's volunteered to drive another release from trunk
in about six months. Would you like to volunteer to drive a release
from the current 0.21 branch?
My latest proposal, a 1.0 branch based on 0.20, contains two questions:
1. Should we make an Apache release that more closely corresponds to
what folks are using in production today (and will be using for a while
yet)?
2. If we're considering the 0.20 mapreduce and filesystem APIs to be 1.0
APIs, and the new mapreduce and filesystem APIs to be 2.0 APIs,
shouldn't our release numbering reflect that? Release numbers are
fundamentally about compatibility declarations. We could instead change
our compatibility rules to specifically mention certain release numbers,
but that feels the wrong way around. Since we've not yet made a 0.21
release, we still have an opportunity to interject a 1.0 release with
the semantics folks expect: its public APIs are stable.
If there's support for this proposal, then I'd volunteer to drive it. I
won't bother to pursue this unless folks think it is worthwhile, so, if
you like it, please speak up. While a release itself cannot be vetoed
and only requires a simple majority, we'll need to vote which patches
would be applied to a 1.0 branch, and those code-change votes require
consensus, so, vetos there would stop the process. So please also speak
up if you strongly oppose this proposal.
Doug
