incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <>
Subject Re: BIgtop 0.3.0 (was: [VOTE] Bigtop 0.3.0: target release date, supported platforms, bill of materials)
Date Wed, 23 Nov 2011 00:02:26 GMT
I firmly believe we should not be releasing anything 0.23-related until a
critical mass of the components are compatible with 0.23.x - there's no
reason we can't get everything ready ahead of time in terms of packaging,
the already-ongoing work on patching components for compatibility, etc, so
that as soon as the stack is ready, we can release.

In fact, I'd personally tend towards waiting to release 0.3.0 until 0.23 is
ready - I don't see a real reason to release off trunk until there's
something significant to release, and 0.23.x and friends would be
significant. If we want to release incremental improvements on top of
0.2.0, do that as 0.2.1, .2, etc.

Mind you, I also firmly believe that we need to get 0.3.0 (based on 0.23.x)
out sooner than later - obviously, we're stuck waiting for components to be
ready, but we should push the components as we have been, we should
consider the possibility of temporarily dropping components from 0.3.0 if
they're being really tardy on compatibility (i.e., if they still don't have
a compatible release coming up by late January, say), and we should be
targeting a release of an 0.23.x-compatible stack, as 0.3.0, by mid
February. 0.2.x is for stability based on the 0.20.20x line, 0.3.x is for
potentially more bleeding-edge stuff based on the 0.23.x line.

Which branch this all is done on is irrelevant to me, really.


On Tue, Nov 22, 2011 at 3:49 PM, Roman Shaposhnik <> wrote:

> On Tue, Nov 22, 2011 at 3:37 PM, Bruno Mahé <> wrote:
> >>> 1/ Latest openSUSE and Fedora are respectively 12.1 and 16
> >> You're absolutely correct. I specifically didn't say "latest" versions,
> >> but stuck with the current ones. Is there any reason you feel
> >> so strongly about bumping the versions of these OSes?
> >
> > I do all my work on latest Fedora/Mageia. So I will not test Fedora 15
> > at all. So you get support for Fedora 16 for free.
> Good point. As long as you're willing to support the neccessary
> infrastructure on bigtop Jenkins -- I have no objections to bumping
> Fedora version.
> > Hence my suggestion to have a stable branch for releases based on the
> > 0.20.20X generation and having trunk based on the next gen Hadoop.
> We had this discussion a couple of month ago and you, yourself, made
> a point that trunk should be reserved to changes which are stable.
> E.g. putting versions of unreleased Apache projects in trunk is a no-no.
> Any reason you're reversing your position now?
> > The stable branch being there for people wishing to use a stable
> > distribution and the coming releases of Bigtop to be used as a solid
> > base for helping projects improving their compatibility with Hadoop
> > 0.23.
> Sure and last time we discussed it, we had a consensus that it is called
> trunk.
> >This will also have the added benefit on helping putting Hadoop
> > 0.23 in more people's hands and improve Bigtop's Hadoop 23 support.
> I don't follow. There's absolutely no difference checking out trunk
> or checking out a branch and building the stack.  And it is THE only
> wait to get Bigtop built for .23. Or you can pull packages from our
> Jenkins job -- either way, I don't see how you can make it *easier*
> to get .23. Care to elaborate?
> > I wouldn't mind at all having a release of Bigtop with just Hadoop 0.23
> > + HBase + other compatible projects, and reactivating these projects one
> > by one as they get compatible with Hadoop 0.23.
> I would strongly -1 that decision. And I'm most certainly would not my name
> to be associated with such a release. Dropping components willy-nilly
> is the biggest threat to Bigtop's credibility as an Apache Bigtdata
> distribution.
> > So we don't have to wait mid 2012 to have a release of Bigtop based on
> > Hadoop 0.23.
> From my stand point -- we absolutely *have* to. Otherwise it will not be
> Bigtop we're talking about.
> > I am rather in favour of "release early and often" and therefore the
> > later option :)
> Now I'm totally confused -- with that motto, why do you NOT want to
> release 0.3.0?
> Thanks,
> Roman.

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