hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhruba Borthakur <dhr...@gmail.com>
Subject Re: HBase move to Apache Top Level Project
Date Fri, 23 Apr 2010 07:49:53 GMT
Agreed, there is no tie-up with hadoop releases, but calling the 0.20.5 as a
1.0 release might be too premature!

thanks,
dhruba


On Fri, Apr 23, 2010 at 12:41 AM, Jonathan Gray <jgray@facebook.com> wrote:

> Agreed that 0.20.5 itself should not be 1.0.  Don't feel that strongly
> about successor of 0.20.5 vs current trunk becoming a 1.0 (hopefully Q3),
> but don't necessarily think we should commit ourselves to the timing of any
> hadoop releases :)
>
> Replication and zookeeper goodness would be nice for 1.0 as well.
>
> > -----Original Message-----
> > From: Dhruba Borthakur [mailto:dhruba@gmail.com]
> > Sent: Friday, April 23, 2010 12:37 AM
> > To: hbase-dev@hadoop.apache.org
> > Subject: Re: HBase move to Apache Top Level Project
> >
> > I think it is too early to cal the next impending 0.20.5 release to be
> > the
> > 1.0 release.
> >
> > hadoop is going to ship 0.22 by Q3 2010, which might be Hadoop 1.0 (?).
> > It
> > might make sense to name the Hbase release aligned with that Hadoop
> > 0.22 to
> > be HBase 1.0.
> >
> > -dhruba
> >
> >
> > On Fri, Apr 23, 2010 at 12:31 AM, Ryan Rawson <ryanobjc@gmail.com>
> > wrote:
> >
> > > When do we want to declare a 1.0?  When we are running on HDFS-265?
> > > When we run on a hdfs that doesnt lose data?
> > >
> > > If the latter, then 0.20.5 is a contender.  There is a lot of
> > > expectation out of a 1.0.
> > >
> > > Other options are going to an alternate scheme, like "version 20"
> > (eg:
> > > oracle 9) but that seems not enough of a distance.
> > >
> > > I would probably go with something like calling 0.20.5 -> 0.9
> > >
> > > then once we are baked, 1.0 later (trunk or branch, not sure,
> > probably
> > > trunk)
> > >
> > >
> > >
> > > On Fri, Apr 23, 2010 at 12:27 AM, Todd Lipcon <todd@cloudera.com>
> > wrote:
> > > > On Fri, Apr 23, 2010 at 12:22 AM, Stack <stack@duboce.net> wrote:
> > > >
> > > >> On Thu, Apr 22, 2010 at 11:44 PM, Jonathan Gray
> > <jgray@facebook.com>
> > > >> wrote:
> > > >> > Now might also be the time to think about breaking from hadoop
> > > numbering
> > > >> (I think this idea has been floating around since the first
> > version we
> > > >> synced).
> > > >> >
> > > >> > We've already agreed to break client compatibility for 0.20.5
> > and it's
> > > >> more than a minor revision.  And I'm sure we'll have another
> > release
> > > between
> > > >> 0.20.5 and 0.21.
> > > >> >
> > > >>
> > > >> So, the new version could be 0.21 but thats not 'breaking from
> > hadoop
> > > >> numbering' and it can't be 1.0.0 .... yet.  What should it be?
> > 0.99.0
> > > >> is kinda dumb.  0.3.0? (We went as far as 0.2.0 on old numbering
> > > >> system).  0.3.0 will be less than 0.21.0 so will mess w/ packaging
> > > >> systems.  0.30.0?
> > > >>
> > > >>
> > > > Both deb and RPM have the concept of a version epoch, so we can
> > make
> > > 0.3.0 >
> > > > 0.20 if we like.
> > > >
> > > > However, it might be confusing for users nonetheless.
> > > >
> > > >
> > > >>
> > > >> > It's also clear that this is going to be by far our most solid
> > release
> > > to
> > > >> date and so might be worthy of new shiny versioning/packaging as a
> > TLP.
> > > >>  Website/docs/wiki refresher to boot.
> > > >> >
> > > >> > Changing the package names is way more invasive to client code
> > but I'm
> > > >> always +1 on making stuff shorter.
> > > >>
> > > >> Might have to keep around the old stuff deprecated.
> > > >>
> > > >> St.Ack
> > > >>
> > > >> >
> > > >> >
> > > >> > Anyways, I'm not doing much production cluster maintenance these
> > days
> > > so
> > > >> these changes would impact me way less than others.  Will welcome
> > > pushback
> > > >> if you guys don't want to deal with this.
> > > >> >
> > > >> > JG
> > > >> >
> > > >> >> -----Original Message-----
> > > >> >> From: Ryan Rawson [mailto:ryanobjc@gmail.com]
> > > >> >> Sent: Thursday, April 22, 2010 11:20 PM
> > > >> >> To: hbase-dev@hadoop.apache.org
> > > >> >> Subject: Re: HBase move to Apache Top Level Project
> > > >> >>
> > > >> >> I am somewhat interested in this :-)
> > > >> >>
> > > >> >> But it can make life difficult for our users... thoughts
> > people?
> > > >> >>
> > > >> >> On Thu, Apr 22, 2010 at 11:17 PM, Karthik K <oss.akk@gmail.com>
> > > wrote:
> > > >> >> > This is great news. Congrats HBase team.
> > > >> >> >
> > > >> >> > (Does this mean, the packages would be refactored as
> > o.a.hbase.* in
> > > >> >> the
> > > >> >> > trunk ? ).
> > > >> >> >
> > > >> >> > --
> > > >> >> >  Karthik.
> > > >> >> >
> > > >> >> >
> > > >> >> > On Thu, Apr 22, 2010 at 10:47 PM, Cosmin Lehene
> > <clehene@adobe.com
> > > >
> > > >> >> wrote:
> > > >> >> >
> > > >> >> >> This is great news!
> > > >> >> >>
> > > >> >> >> On Apr 22, 2010, at 8:32 PM, Stack wrote:
> > > >> >> >>
> > > >> >> >> > The board yesterday passed a resolution making
HBase a
> > TLP.
> > > >> >> >> >
> > > >> >> >> > I filed an infrastructure issue to start the
move:
> > > >> >> >> >
> > > >> >> >> > https://issues.apache.org/jira/browse/INFRA-2641
> > > >> >> >> >
> > > >> >> >> > The primary disruption to developers will be
when the
> > subversion
> > > >> >> >> > repository is renamed.  We'll send out a note
before we do
> > this,
> > > >> >> then
> > > >> >> >> > developers can use 'svn switch' to update their
repos
> > (There is
> > > no
> > > >> >> >> > apache git repo that I know of... I asked just
in case)
> > > >> >> >> >
> > > >> >> >> We already use the apache git.apache.org mirror
for HBase.
> > I've
> > > also
> > > >> >> seen
> > > >> >> >> the GitHub mirror http://github.com/apache/hbase
and thought
> > > there
> > > >> >> might
> > > >> >> >> be some plans for migration.
> > > >> >> >>
> > > >> >> >> > One other issue is the wiki.  I don't think
it's easy to
> > rename
> > > a
> > > >> >> >> > subtree from a Moin Moin wiki to a new wiki.
 Fortunately
> > we
> > > don't
> > > >> >> >> > have many wiki pages and could cut and paste
them
> > manually.
> > > >> >> >> > Alternately, we could switch to using confluence
for our
> > wiki.
> > > >> >> >> > Thoughts?
> > > >> >> >> >
> > > >> >> >> Confluence has a good integration with Jira (being
both
> > developed
> > > by
> > > >> >> >> Atlassian). It's functionally advanced and looks
better. So
> > +1 for
> > > >> >> that as
> > > >> >> >> well.
> > > >> >> >>
> > > >> >> >> Cosmin
> > > >> >> >>
> > > >> >> >> > St.Ack
> > > >> >> >> > (Above shamelessly a copy of Doug's mail to
the Avro list)
> > > >> >> >>
> > > >> >> >>
> > > >> >> >
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Todd Lipcon
> > > > Software Engineer, Cloudera
> > > >
> > >
> >
> >
> >
> > --
> > Connect to me at http://www.facebook.com/dhruba
>



-- 
Connect to me at http://www.facebook.com/dhruba

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