Development release series?

[Todd Lipcon <to...@cloudera.com>]

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

RE: Development release series?

[Jonathan Gray <jg...@facebook.com>]

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 [mailto:todd@cloudera.com]
> 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 <jg...@facebook.com>
> 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

Re: Development release series?

[Todd Lipcon <to...@cloudera.com>]

On Thu, May 20, 2010 at 11:12 AM, Jonathan Gray <jg...@facebook.com> 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

RE: Development release series?

[Jonathan Gray <jg...@facebook.com>]

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 [mailto:todd@cloudera.com]
> 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

Re: Development release series?

[Todd Lipcon <to...@cloudera.com>]

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 <to...@cloudera.com> wrote:

> On Thu, May 20, 2010 at 12:10 PM, Stack <st...@duboce.net> 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 <to...@cloudera.com> 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

Re: Development release series?

[Todd Lipcon <to...@cloudera.com>]

On Thu, May 20, 2010 at 12:10 PM, Stack <st...@duboce.net> 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 <to...@cloudera.com> 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

Re: Development release series?

[Stack <st...@duboce.net>]

+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 <to...@cloudera.com> 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
>

RE: Development release series?

[Jonathan Gray <jg...@facebook.com>]

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 [mailto:apurtell@apache.org]
> 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
> 
> 
> 
> 

Re: Development release series?

[Andrew Purtell <ap...@apache.org>]

+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