Whats our thinking on 0.92.0 now May 1st has passed? Interestingly,
the numbers of blockers and criticals are the same as Andrew reports
below in the threads' first message (we won some since his email was
written but then some new ones showed up since). Online merge and
schema edits have not
From: Stack st...@duboce.net
Subject: Re: putting a border around 0.92 release
To: u...@hbase.apache.org, apurt...@apache.org
Cc: dev@hbase.apache.org
Date: Monday, May 2, 2011, 10:48 AM
Whats our thinking on 0.92.0 now May 1st has passed? Interestingly,
the numbers of blockers and criticals
I'm in favor of releasing major versions more often so that the
changes be less disruptive, the sooner the better.
We'll never know for sure, but I wonder if releasing more often
compared to waiting for those features would put those same features
in the hands of the users sooner or later. Like
: putting a border around 0.92 release
To: dev@hbase.apache.org
Cc: Jean-Daniel Cryans jdcry...@apache.org
Date: Wednesday, March 2, 2011, 2:39 PM
On Tue, Mar 1, 2011 at 9:34 AM,
Jean-Daniel Cryans jdcry...@apache.org
wrote:
That's a pretty good interview, thanks for sharing!
S is our
with it) for at least the next year, regardless of how
whiz-bang 0.92 or future releases will be.
-Todd
--- On Wed, 3/2/11, Todd Lipcon t...@cloudera.com wrote:
From: Todd Lipcon t...@cloudera.com
Subject: Re: putting a border around 0.92 release
To: dev@hbase.apache.org
Cc: Jean-Daniel Cryans jdcry
will be supporting 0.90.1 (or something that's 100%
compatible with it) for at least the next year, regardless of how
whiz-bang 0.92 or future releases will be.
-Todd
--- On Wed, 3/2/11, Todd Lipcon t...@cloudera.com wrote:
From: Todd Lipcon t...@cloudera.com
Subject: Re: putting a border around 0.92
I knew I should I have used rant /rant around my reply!
Was the second 0.89 a failure? If I recall correctly, various people
ran it, found bugs, and reported them. We then fixed the bugs for the
third 0.89 release. Doing the broken one got us all testing a similar
set of bits (including some
I'd generally vote for a time-based release. The big feature
releases while are good for attracting new users with new features,
present a problem in that it can really delay releases for a long
time. More releases are better! If a feature takes more than 3
months then it's too big to implement
Yeah, time-based. May 1st for 0.92 branch! +1 on big changes out on
branch keeping trunk relatively releasable at all times. I like your
list J-D. 0.92 should run on hadoop-0.20 through hadoop trunk at time
of our 0.92 branch. If all are good w/ that, lets do a pass over 0.92
issues so its
I think we tried a couple of times to release according to a schedule
in the past but always failed, be it 0.2, 0.20 or 0.90, and always
ended with something like an alpha or preview release at agreed-upon
time.
On on hand, releasing more often would give users access to features
earlier (those
On Mon, Feb 28, 2011 at 2:18 PM, Jean-Daniel Cryans jdcry...@apache.org wrote:
I think we tried a couple of times to release according to a schedule
in the past but always failed, be it 0.2, 0.20 or 0.90, and always
ended with something like an alpha or preview release at agreed-upon
time.
+1 on 0.91 and have something for the summit. Also great to box the feature set
now as I will base the book on 0.92 - anything else would futile.
On Feb 26, 2011, at 23:24, Jean-Daniel Cryans jdcry...@apache.org wrote:
Woah those are huge tasks!
Also to consider:
- integration with
Stack and I were chatting on IRC about settling with should get into 0.92
before pulling the trigger on the release.
Stack thinks we need online region schema editing. I agree because per-table
coprocessor loading is configured via table attributes. We'd also need some
kind of notification of
13 matches
Mail list logo
