Tom White wrote:
I think the focus should be on getting an alpha release
out, so I suggest we create a new 0.21 branch from trunk
Another release we might consider is 1.0 based on 0.20. We'd then have
releases that correspond to what folks are actually using in production.
This would also rationalize our release numbering, since many have
expressed that 0.20 APIs should be treated as 1.0 APIs.
A 1.0 release based off 0.20 would give us a chance to state more
precisely the 1.0 API that we intend to support long-term. For example,
we might un-mark the old mapreduce APIs as deprecated in a 1.0 release,
and mark the new mapreduce APIs as experimental and unstable there.
Programs that use only public stable features in 1.0 could be then
guaranteed to run for a long-time hence.
It would also be good to get HDFS-200 into 1.0. That might be the
fastest route to providing a stable append for HBase.
Y!'s 0.20+security could become the basis of a 1.1 release.
The next release from trunk might then be called 2.0 alpha. It would
support 1.0 APIs, but they'd be deprecated in favor of newer API for
mapreduce and filesystems. We could pursue releasing 1.0 and 2.0 alpha
in parallel.
Thoughts?
Doug
