Hey all,
In a recent discussion, we noticed that the 0.20.2 HDFS client will not be
wire-compatible with 0.20.0 or 0.20.1 due to the inclusion of HDFS-793
(required for HDFS-101). This begs a few questions:
1) Although we certainly do not guarantee wire compatibility between minor
versions (0.20
On 1/5/10 11:29 AM, "Todd Lipcon" wrote:
> 1) Although we certainly do not guarantee wire compatibility between minor
> versions (0.20 -> 0.21) have we previously implied wire compatibility
> between bugfix releases?
IIRC, it has been implied and was a goal but not officially written anywhere
pub
On Jan 5, 2010, at 11:29 AM, Todd Lipcon wrote:
1) Although we certainly do not guarantee wire compatibility between
minor
versions (0.20 -> 0.21) have we previously implied wire compatibility
between bugfix releases?
Correction. Pre-1.0, the 0.N to 0.N+1 is a major upgrade. After 1.0,
1.
On Jan 5, 2010, at 2:06 PM, Owen O'Malley wrote:
On Jan 5, 2010, at 11:29 AM, Todd Lipcon wrote:
> 1) Although we certainly do not guarantee wire compatibility between
> minor
> versions (0.20 -> 0.21) have we previously implied wire
compatibility
> between bugfix releases?
Correction. Pr
Owen O'Malley wrote:
Correction. Pre-1.0, the 0.N to 0.N+1 is a major upgrade. After 1.0, 1.N
to 1.N+1 is a minor. In both cases, X.Y.z to X.Y.z+1 is a patch release.
I thought we had it documented somewhere, but can't find it.
http://wiki.apache.org/hadoop/Roadmap
Doug
>From the HBase point of view, we would want to include hadoop
0.20.2-dev in hbase 0.20.3 specifically for HDFS-101 (127 would also
be nice since we could stop patching the jar we distribute). We also
share the same rules as hadoop and we don't want to break
compatibility between point releases (we
Hairong was having difficulty getting this message through the spam
filters.
-- Owen
Start of the message:
> I would like Hairong to consider if she could fix the issue in 0.20
> without the incompatible change.
It is possible that I fix the issue in 0.20 without breaking th
> I would like to propose that we pull out HDFS-793 and HDFS-101 from 0.20.
+1 to pulling it out. This code is very tricky and is dangerous to change in
a minor release.
thanks,
dhruba
On Jan 6, 2010, at 10:31 AM, Dhruba Borthakur wrote:
I would like to propose that we pull out HDFS-793 and HDFS-101 from
0.20.
+1 to pulling it out. This code is very tricky and is dangerous to
change in
a minor release.
+1 to pulling it out.
-- Owen
On Wed, Jan 6, 2010 at 10:31 AM, Dhruba Borthakur wrote:
> > I would like to propose that we pull out HDFS-793 and HDFS-101 from 0.20.
>
> +1 to pulling it out. This code is very tricky and is dangerous to change
> in
> a minor release.
>
>
-0 to pulling it out - I agree that it's very tricky, bu
On 1/6/10 10:54 AM, "Todd Lipcon" wrote:
> -0 to pulling it out - I agree that it's very tricky, but I think HDFS-101
> is a pretty big bug to knowingly leave in. In my experience this has been
> the singular cause behind a lot of HDFS write problems when a cluster has a
> couple of "bad egg" n
Start of the message:
> I would like Hairong to consider if she could fix the issue in 0.20
> without the incompatible change.
It is possible that I fix the issue in 0.20 without breaking the
compatibility. But I am worried about the code stability if we take
this approach.
12 matches
Mail list logo