Grokbase Groups HBase dev May 2010
FAQ
Hi all,

I've been throwing this idea around to a few people individually over the
last week, but wanted to raise it on the list for a wider discussion:

I'd like to propose inserting a "development release series" in between 0.20
and our next release (the one that will have full durability, significant
master fixup, etc). In terms of what this release series would be:

1) Frequent Releases. We should try to do a release once a month between now
and the next major release.

2) Low Amount of QA. We should not make any guarantees that the releases
have been heavily tested. They should certainly pass unit tests and basic
functional tests (eg PE and other cluster smoke tests) but we would not go
through multi-week rc cycles.

3) Clearly communicated "Development" status. We do not want new users on
this release unless they are aware they are trying what is essentially a
trunk snapshot. We should feel free to have serious known bugs in these
development releases and not address them until the next release.

4) Given the "development" status of this build, I think we should drop the
"no breaking changes between point releases" restriction. That way we're
fine to make RPC/API fixups as the series progresses.

5) Normal policies regarding license cleanliness, release voting, etc. Kind
of goes without saying, but we still need to be careful to maintain proper
licensing, etc, and not let anything slip in that would be Apache 2
incompatible, etc.

Now, the reasons I am proposing this:

1) We have a vibrant user/contributor community which has a diverse set of
workloads. The core developer community has a smaller (but growing) set of
workloads. There have been a few cases where a release has worked great for
the workloads of the core team, but after a release we've found a serious
bug that only affects some feature or access pattern that hasn't been
sufficiently tested during development. Doing frequent development releases
gives reasonable milestones for users to try upcoming releases for their
workloads and give feedback if there has been a regression.

Two particular examples of the above are the ExplicitColumnTracker infinite
loop bug in 0.20.4, and the META caching regression in 0.20.3.

2) Given the recent switch to Maven, I think we will find that the first
post-maven release will bring new difficulties we haven't worked through in
the past. We should make sure we know how to release off the new build
system, and that all of the various shell scripts and integration points
still work. Doing some "practice" releases before the real thing will allow
us to start tackling these problems early.

3) It's been quite some time since the last major release. Doing a fast
progression of a few development releases is a good way to highlight the
recent surge of HBase development and build anticipation for what's coming.

4) On a selfish note, I would like to attempt to include a "beta" release of
durable HBase packaged in CDH3 in June. We will certainly not be ready for
the next major release at that point. I can certainly pick an svn revision
and build my own release off that, but if the version number in CDH lines up
with a version number of this development series, I think it will present
less user confusion, etc.

I am also happy to volunteer myself to release manage at least the first of
this series. Though I do not have committer access, the Apache rules
generally allow anyone to propose a release tarball, so long as it's voted
on by the PMC.

Thanks
-Todd

--
Todd Lipcon
Software Engineer, Cloudera

Search Discussions

  • Andrew Purtell at May 20, 2010 at 5:47 pm
    +1

    Since Hadoop 0.21 is probably going to be tagged "unstabled" as I hear, why don't we do a development release series also as 0.21? The release series which follows that will have full durability could be called 0.90, in anticipation of the one following to be 1.0.

    - Andy
  • Jonathan Gray at May 20, 2010 at 6:04 pm
    But our development release won't be targeted at Hadoop 0.21, so isn't this the confusion we want to avoid?
    -----Original Message-----
    From: Andrew Purtell
    Sent: Thursday, May 20, 2010 10:47 AM
    To: dev@hbase.apache.org
    Subject: Re: Development release series?

    +1

    Since Hadoop 0.21 is probably going to be tagged "unstabled" as I hear,
    why don't we do a development release series also as 0.21? The release
    series which follows that will have full durability could be called
    0.90, in anticipation of the one following to be 1.0.

    - Andy


  • Jonathan Gray at May 20, 2010 at 6:14 pm
    In principle I'm +1 on doing a development release. I'd like to see it happen in early June, basically at the same time we do a feature freeze on trunk for the real release. So any big changes that we want to get in to the next big release should be committed to trunk at the time we cut the dev release.

    It's like a very early go at an RC. But I like calling it a dev release rather than an RC because for us the RCs are really things we only put out there when we expect/hope that they become the release. In other projects an RC is like a dev release, so doing a dev release can give us the best of both worlds.

    I'm not particular about the release manager except that this person would have veto rights on any new features for the next big release (if we follow my above logic that trunk should be feature frozen when we cut the dev release), so there is some power to the position though just for a dev release. In general I think the release manager should be a committer but exceptions can always be made.

    We've never been a group to stick absolutely to rules like feature freezes, and I like that, so other stuff _can_ possibly sneak in after the dev release (I'm sure I'll be pushing for a few) if there is mostly consensus. But it's a good target/ideal to have in mind. Getting a new feature out into the world gives it a chance to bake before the real release. Just thinking about this is lighting a fire under my own ass to get moving on some of the bigger changes I'd like to get in. :)

    Oh and agree 100% that getting our first mavenized version into the hands of users sooner than later is important. Another good reason for a dev release.

    JG
    -----Original Message-----
    From: Todd Lipcon
    Sent: Thursday, May 20, 2010 10:31 AM
    To: dev@hbase.apache.org
    Subject: Development release series?

    Hi all,

    I've been throwing this idea around to a few people individually over
    the
    last week, but wanted to raise it on the list for a wider discussion:

    I'd like to propose inserting a "development release series" in between
    0.20
    and our next release (the one that will have full durability,
    significant
    master fixup, etc). In terms of what this release series would be:

    1) Frequent Releases. We should try to do a release once a month
    between now
    and the next major release.

    2) Low Amount of QA. We should not make any guarantees that the
    releases
    have been heavily tested. They should certainly pass unit tests and
    basic
    functional tests (eg PE and other cluster smoke tests) but we would not
    go
    through multi-week rc cycles.

    3) Clearly communicated "Development" status. We do not want new users
    on
    this release unless they are aware they are trying what is essentially
    a
    trunk snapshot. We should feel free to have serious known bugs in these
    development releases and not address them until the next release.

    4) Given the "development" status of this build, I think we should drop
    the
    "no breaking changes between point releases" restriction. That way
    we're
    fine to make RPC/API fixups as the series progresses.

    5) Normal policies regarding license cleanliness, release voting, etc.
    Kind
    of goes without saying, but we still need to be careful to maintain
    proper
    licensing, etc, and not let anything slip in that would be Apache 2
    incompatible, etc.

    Now, the reasons I am proposing this:

    1) We have a vibrant user/contributor community which has a diverse set
    of
    workloads. The core developer community has a smaller (but growing) set
    of
    workloads. There have been a few cases where a release has worked great
    for
    the workloads of the core team, but after a release we've found a
    serious
    bug that only affects some feature or access pattern that hasn't been
    sufficiently tested during development. Doing frequent development
    releases
    gives reasonable milestones for users to try upcoming releases for
    their
    workloads and give feedback if there has been a regression.

    Two particular examples of the above are the ExplicitColumnTracker
    infinite
    loop bug in 0.20.4, and the META caching regression in 0.20.3.

    2) Given the recent switch to Maven, I think we will find that the
    first
    post-maven release will bring new difficulties we haven't worked
    through in
    the past. We should make sure we know how to release off the new build
    system, and that all of the various shell scripts and integration
    points
    still work. Doing some "practice" releases before the real thing will
    allow
    us to start tackling these problems early.

    3) It's been quite some time since the last major release. Doing a fast
    progression of a few development releases is a good way to highlight
    the
    recent surge of HBase development and build anticipation for what's
    coming.

    4) On a selfish note, I would like to attempt to include a "beta"
    release of
    durable HBase packaged in CDH3 in June. We will certainly not be ready
    for
    the next major release at that point. I can certainly pick an svn
    revision
    and build my own release off that, but if the version number in CDH
    lines up
    with a version number of this development series, I think it will
    present
    less user confusion, etc.

    I am also happy to volunteer myself to release manage at least the
    first of
    this series. Though I do not have committer access, the Apache rules
    generally allow anyone to propose a release tarball, so long as it's
    voted
    on by the PMC.

    Thanks
    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at May 20, 2010 at 6:21 pm

    On Thu, May 20, 2010 at 11:12 AM, Jonathan Gray wrote:

    In principle I'm +1 on doing a development release. I'd like to see it
    happen in early June, basically at the same time we do a feature freeze on
    trunk for the real release. So any big changes that we want to get in to
    the next big release should be committed to trunk at the time we cut the dev
    release.
    I agree on June timeframe - this also lines up well with the Hadoop Summit
    at the end of June. A few of us are probably giving talks and it will be
    nice to say "these things are in development release 0.X.0" instead of just
    trunk

    I don't think we should *quite* feature freeze for the dev releases. We
    should freeze "major" features perhaps, but I think if we introduce feature
    gating on these releases instead of just time gating, we'll end up not
    getting things out.

    It's like a very early go at an RC. But I like calling it a dev release
    rather than an RC because for us the RCs are really things we only put out
    there when we expect/hope that they become the release. In other projects
    an RC is like a dev release, so doing a dev release can give us the best of
    both worlds. +1
    I'm not particular about the release manager except that this person would
    have veto rights on any new features for the next big release (if we follow
    my above logic that trunk should be feature frozen when we cut the dev
    release), so there is some power to the position though just for a dev
    release. In general I think the release manager should be a committer but
    exceptions can always be made.
    Fair enough, I'd be happy if you or another committer were release manager
    as well. I was just volunteering in case no one else wanted to.


    We've never been a group to stick absolutely to rules like feature freezes,
    and I like that, so other stuff _can_ possibly sneak in after the dev
    release (I'm sure I'll be pushing for a few) if there is mostly consensus.
    But it's a good target/ideal to have in mind. Getting a new feature out
    into the world gives it a chance to bake before the real release. Just
    thinking about this is lighting a fire under my own ass to get moving on
    some of the bigger changes I'd like to get in. :)
    +1, can't wait for your master fixes!

    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Jonathan Gray at May 20, 2010 at 6:33 pm
    You're right. The dev release should be more about time gating than feature gating to push things forward and not hold back. But things like the master fix would benefit greatly from getting into the dev release. It's always in the wild that people get these weird overlapping regions, dupe assignment, WrongRegionExceptions, etc...
    -----Original Message-----
    From: Todd Lipcon
    Sent: Thursday, May 20, 2010 11:20 AM
    To: dev@hbase.apache.org
    Subject: Re: Development release series?
    On Thu, May 20, 2010 at 11:12 AM, Jonathan Gray wrote:

    In principle I'm +1 on doing a development release. I'd like to see it
    happen in early June, basically at the same time we do a feature freeze on
    trunk for the real release. So any big changes that we want to get in to
    the next big release should be committed to trunk at the time we cut the dev
    release.
    I agree on June timeframe - this also lines up well with the Hadoop
    Summit
    at the end of June. A few of us are probably giving talks and it will
    be
    nice to say "these things are in development release 0.X.0" instead of
    just
    trunk

    I don't think we should *quite* feature freeze for the dev releases. We
    should freeze "major" features perhaps, but I think if we introduce
    feature
    gating on these releases instead of just time gating, we'll end up not
    getting things out.

    It's like a very early go at an RC. But I like calling it a dev release
    rather than an RC because for us the RCs are really things we only put out
    there when we expect/hope that they become the release. In other projects
    an RC is like a dev release, so doing a dev release can give us the best of
    both worlds. +1
    I'm not particular about the release manager except that this person would
    have veto rights on any new features for the next big release (if we follow
    my above logic that trunk should be feature frozen when we cut the dev
    release), so there is some power to the position though just for a dev
    release. In general I think the release manager should be a
    committer but
    exceptions can always be made.
    Fair enough, I'd be happy if you or another committer were release
    manager
    as well. I was just volunteering in case no one else wanted to.


    We've never been a group to stick absolutely to rules like feature freezes,
    and I like that, so other stuff _can_ possibly sneak in after the dev
    release (I'm sure I'll be pushing for a few) if there is mostly
    consensus.
    But it's a good target/ideal to have in mind. Getting a new feature out
    into the world gives it a chance to bake before the real release. Just
    thinking about this is lighting a fire under my own ass to get moving on
    some of the bigger changes I'd like to get in. :)
    +1, can't wait for your master fixes!

    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Stack at May 20, 2010 at 7:10 pm
    +1 as long as we are super clean on the messaging about how these dev
    releases differ from what we usually put out (#3 in the below). Also,
    we need to be clear that these dev releases are driving toward the
    next major release of hbase and will stop when that is published.

    #4 in the below, does it apply to migration? Should we gurantee that
    evrelease#103 will always be able to run atop the data written with
    devrelease#102? Lets not guarantee no-migration because 1.) I don't
    think it'll be an issue w/ this coming release -- no big data format
    changes planned -- and 2.) migrations are time-consuming, a
    distraction from forward dev (Its unlikely that the characters who
    depend on a migration working will be playing w/ dev-releases
    anyways).

    One healthy development I see coming of this is that it'll spur the
    development of release evaluation tools and tests.

    You don't have to volunteer as release manager Todd. Your time would
    be better served bug fixing (smile).

    St.Ack
    On Thu, May 20, 2010 at 10:30 AM, Todd Lipcon wrote:
    Hi all,

    I've been throwing this idea around to a few people individually over the
    last week, but wanted to raise it on the list for a wider discussion:

    I'd like to propose inserting a "development release series" in between 0.20
    and our next release (the one that will have full durability, significant
    master fixup, etc). In terms of what this release series would be:

    1) Frequent Releases. We should try to do a release once a month between now
    and the next major release.

    2) Low Amount of QA. We should not make any guarantees that the releases
    have been heavily tested. They should certainly pass unit tests and basic
    functional tests (eg PE and other cluster smoke tests) but we would not go
    through multi-week rc cycles.

    3) Clearly communicated "Development" status. We do not want new users on
    this release unless they are aware they are trying what is essentially a
    trunk snapshot. We should feel free to have serious known bugs in these
    development releases and not address them until the next release.

    4) Given the "development" status of this build, I think we should drop the
    "no breaking changes between point releases" restriction. That way we're
    fine to make RPC/API fixups as the series progresses.

    5) Normal policies regarding license cleanliness, release voting, etc.  Kind
    of goes without saying, but we still need to be careful to maintain proper
    licensing, etc, and not let anything slip in that would be Apache 2
    incompatible, etc.

    Now, the reasons I am proposing this:

    1) We have a vibrant user/contributor community which has a diverse set of
    workloads. The core developer community has a smaller (but growing) set of
    workloads. There have been a few cases where a release has worked great for
    the workloads of the core team, but after a release we've found a serious
    bug that only affects some feature or access pattern that hasn't been
    sufficiently tested during development. Doing frequent development releases
    gives reasonable milestones for users to try upcoming releases for their
    workloads and give feedback if there has been a regression.

    Two particular examples of the above are the ExplicitColumnTracker infinite
    loop bug in 0.20.4, and the META caching regression in 0.20.3.

    2) Given the recent switch to Maven, I think we will find that the first
    post-maven release will bring new difficulties we haven't worked through in
    the past. We should make sure we know how to release off the new build
    system, and that all of the various shell scripts and integration points
    still work. Doing some "practice" releases before the real thing will allow
    us to start tackling these problems early.

    3) It's been quite some time since the last major release. Doing a fast
    progression of a few development releases is a good way to highlight the
    recent surge of HBase development and build anticipation for what's coming.

    4) On a selfish note, I would like to attempt to include a "beta" release of
    durable HBase packaged in CDH3 in June. We will certainly not be ready for
    the next major release at that point. I can certainly pick an svn revision
    and build my own release off that, but if the version number in CDH lines up
    with a version number of this development series, I think it will present
    less user confusion, etc.

    I am also happy to volunteer myself to release manage at least the first of
    this series. Though I do not have committer access, the Apache rules
    generally allow anyone to propose a release tarball, so long as it's voted
    on by the PMC.

    Thanks
    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at May 20, 2010 at 7:14 pm

    On Thu, May 20, 2010 at 12:10 PM, Stack wrote:

    +1 as long as we are super clean on the messaging about how these dev
    releases differ from what we usually put out (#3 in the below). Also,
    we need to be clear that these dev releases are driving toward the
    next major release of hbase and will stop when that is published.
    Yep, though flipflopping odd/even dev/stable is a tried and true strategy
    that we might consider in the future. But this proposal is just about doing
    it this one time. If it works well, maybe we can use it again later.

    #4 in the below, does it apply to migration? Should we gurantee that
    evrelease#103 will always be able to run atop the data written with
    devrelease#102? Lets not guarantee no-migration because 1.) I don't
    think it'll be an issue w/ this coming release -- no big data format
    changes planned -- and 2.) migrations are time-consuming, a
    distraction from forward dev (Its unlikely that the characters who
    depend on a migration working will be playing w/ dev-releases
    anyways).
    I think inasmuch as we don't want to force a migration 20->DurableRelease,
    we don't want to force migrations in between development releases. Let's
    cross this bridge if we have any data format changes, can call a vote, etc.
    But like you said I don't think we have any planned.

    One healthy development I see coming of this is that it'll spur the
    development of release evaluation tools and tests.

    You don't have to volunteer as release manager Todd. Your time would
    be better served bug fixing (smile).

    St.Ack
    On Thu, May 20, 2010 at 10:30 AM, Todd Lipcon wrote:
    Hi all,

    I've been throwing this idea around to a few people individually over the
    last week, but wanted to raise it on the list for a wider discussion:

    I'd like to propose inserting a "development release series" in between 0.20
    and our next release (the one that will have full durability, significant
    master fixup, etc). In terms of what this release series would be:

    1) Frequent Releases. We should try to do a release once a month between now
    and the next major release.

    2) Low Amount of QA. We should not make any guarantees that the releases
    have been heavily tested. They should certainly pass unit tests and basic
    functional tests (eg PE and other cluster smoke tests) but we would not go
    through multi-week rc cycles.

    3) Clearly communicated "Development" status. We do not want new users on
    this release unless they are aware they are trying what is essentially a
    trunk snapshot. We should feel free to have serious known bugs in these
    development releases and not address them until the next release.

    4) Given the "development" status of this build, I think we should drop the
    "no breaking changes between point releases" restriction. That way we're
    fine to make RPC/API fixups as the series progresses.

    5) Normal policies regarding license cleanliness, release voting, etc. Kind
    of goes without saying, but we still need to be careful to maintain proper
    licensing, etc, and not let anything slip in that would be Apache 2
    incompatible, etc.

    Now, the reasons I am proposing this:

    1) We have a vibrant user/contributor community which has a diverse set of
    workloads. The core developer community has a smaller (but growing) set of
    workloads. There have been a few cases where a release has worked great for
    the workloads of the core team, but after a release we've found a serious
    bug that only affects some feature or access pattern that hasn't been
    sufficiently tested during development. Doing frequent development releases
    gives reasonable milestones for users to try upcoming releases for their
    workloads and give feedback if there has been a regression.

    Two particular examples of the above are the ExplicitColumnTracker infinite
    loop bug in 0.20.4, and the META caching regression in 0.20.3.

    2) Given the recent switch to Maven, I think we will find that the first
    post-maven release will bring new difficulties we haven't worked through in
    the past. We should make sure we know how to release off the new build
    system, and that all of the various shell scripts and integration points
    still work. Doing some "practice" releases before the real thing will allow
    us to start tackling these problems early.

    3) It's been quite some time since the last major release. Doing a fast
    progression of a few development releases is a good way to highlight the
    recent surge of HBase development and build anticipation for what's coming.
    4) On a selfish note, I would like to attempt to include a "beta" release of
    durable HBase packaged in CDH3 in June. We will certainly not be ready for
    the next major release at that point. I can certainly pick an svn revision
    and build my own release off that, but if the version number in CDH lines up
    with a version number of this development series, I think it will present
    less user confusion, etc.

    I am also happy to volunteer myself to release manage at least the first of
    this series. Though I do not have committer access, the Apache rules
    generally allow anyone to propose a release tarball, so long as it's voted
    on by the PMC.

    Thanks
    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Todd Lipcon at May 21, 2010 at 8:42 pm
    Sounds like there's general consensus. I don't think we need an official
    vote now - let's do that when we make our first release in this series in
    June.

    As I understand it, the following points are what we concluded:
    - We will do some development releases between 0.20.N and the stable durable
    version.
    - These will be somewhat rc-like, generally cluster tested, but fine if they
    have known bugs and small enhancements still to come.
    - We will try to get the major changes done (particularly master fixup)
    before releasing the first in this series, but we will endeavor to make
    these time-based releases rather than feature-based.
    - After we do a release on this series, we won't add major new changes to
    this branch without some kind of vote/discussion.
    - We will publicize the fact that these are development releases, and
    encourage people to try them on their development clusters, but not
    recommend them for general use.

    If anyone disagrees with the above, shout!

    -Todd

    On Thu, May 20, 2010 at 12:13 PM, Todd Lipcon wrote:
    On Thu, May 20, 2010 at 12:10 PM, Stack wrote:

    +1 as long as we are super clean on the messaging about how these dev
    releases differ from what we usually put out (#3 in the below). Also,
    we need to be clear that these dev releases are driving toward the
    next major release of hbase and will stop when that is published.
    Yep, though flipflopping odd/even dev/stable is a tried and true strategy
    that we might consider in the future. But this proposal is just about doing
    it this one time. If it works well, maybe we can use it again later.

    #4 in the below, does it apply to migration? Should we gurantee that
    evrelease#103 will always be able to run atop the data written with
    devrelease#102? Lets not guarantee no-migration because 1.) I don't
    think it'll be an issue w/ this coming release -- no big data format
    changes planned -- and 2.) migrations are time-consuming, a
    distraction from forward dev (Its unlikely that the characters who
    depend on a migration working will be playing w/ dev-releases
    anyways).
    I think inasmuch as we don't want to force a migration 20->DurableRelease,
    we don't want to force migrations in between development releases. Let's
    cross this bridge if we have any data format changes, can call a vote, etc.
    But like you said I don't think we have any planned.

    One healthy development I see coming of this is that it'll spur the
    development of release evaluation tools and tests.

    You don't have to volunteer as release manager Todd. Your time would
    be better served bug fixing (smile).

    St.Ack
    On Thu, May 20, 2010 at 10:30 AM, Todd Lipcon wrote:
    Hi all,

    I've been throwing this idea around to a few people individually over the
    last week, but wanted to raise it on the list for a wider discussion:

    I'd like to propose inserting a "development release series" in between 0.20
    and our next release (the one that will have full durability,
    significant
    master fixup, etc). In terms of what this release series would be:

    1) Frequent Releases. We should try to do a release once a month between now
    and the next major release.

    2) Low Amount of QA. We should not make any guarantees that the releases
    have been heavily tested. They should certainly pass unit tests and basic
    functional tests (eg PE and other cluster smoke tests) but we would not go
    through multi-week rc cycles.

    3) Clearly communicated "Development" status. We do not want new users on
    this release unless they are aware they are trying what is essentially a
    trunk snapshot. We should feel free to have serious known bugs in these
    development releases and not address them until the next release.

    4) Given the "development" status of this build, I think we should drop the
    "no breaking changes between point releases" restriction. That way we're
    fine to make RPC/API fixups as the series progresses.

    5) Normal policies regarding license cleanliness, release voting, etc. Kind
    of goes without saying, but we still need to be careful to maintain proper
    licensing, etc, and not let anything slip in that would be Apache 2
    incompatible, etc.

    Now, the reasons I am proposing this:

    1) We have a vibrant user/contributor community which has a diverse set of
    workloads. The core developer community has a smaller (but growing) set of
    workloads. There have been a few cases where a release has worked great for
    the workloads of the core team, but after a release we've found a serious
    bug that only affects some feature or access pattern that hasn't been
    sufficiently tested during development. Doing frequent development releases
    gives reasonable milestones for users to try upcoming releases for their
    workloads and give feedback if there has been a regression.

    Two particular examples of the above are the ExplicitColumnTracker infinite
    loop bug in 0.20.4, and the META caching regression in 0.20.3.

    2) Given the recent switch to Maven, I think we will find that the first
    post-maven release will bring new difficulties we haven't worked through in
    the past. We should make sure we know how to release off the new build
    system, and that all of the various shell scripts and integration points
    still work. Doing some "practice" releases before the real thing will allow
    us to start tackling these problems early.

    3) It's been quite some time since the last major release. Doing a fast
    progression of a few development releases is a good way to highlight the
    recent surge of HBase development and build anticipation for what's coming.
    4) On a selfish note, I would like to attempt to include a "beta"
    release of
    durable HBase packaged in CDH3 in June. We will certainly not be ready for
    the next major release at that point. I can certainly pick an svn revision
    and build my own release off that, but if the version number in CDH lines up
    with a version number of this development series, I think it will present
    less user confusion, etc.

    I am also happy to volunteer myself to release manage at least the first of
    this series. Though I do not have committer access, the Apache rules
    generally allow anyone to propose a release tarball, so long as it's voted
    on by the PMC.

    Thanks
    -Todd

    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera


    --
    Todd Lipcon
    Software Engineer, Cloudera

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieshbase, hadoop
postedMay 20, '10 at 5:31p
activeMay 21, '10 at 8:42p
posts9
users4
websitehbase.apache.org

People

Translate

site design / logo © 2021 Grokbase