hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Development release series?
Date Thu, 20 May 2010 18:19:40 GMT
On Thu, May 20, 2010 at 11:12 AM, Jonathan Gray <jgray@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message