Oh, sorry, yes, I misunderstood. Nightly builds of Bigtop trunk would certainly make a lot more sense than any sort of nightly build of the trunks of each supported application. :)
On Tue, Jun 7, 2016 at 3:24 PM Konstantin Boudnik <[email protected]> wrote: > On Tue, Jun 07, 2016 at 09:08PM, Jonathan Kelly wrote: > > I'm not sure this will work very well, since many apps depend upon other > > apps but have not yet upgraded to support the latest version of their > > dependencies. > > > > For example, Spark 2.0 is going to be released in the next month or so, > but > > Hive, Mahout, Oozie, Zeppelin and possibly more do not yet support Spark > > 2.0. As another example, Hive 2.1 will be released somewhat soon too, but > > some apps might not yet support Hive 2.x, let alone Hive 2.1. (Bigtop is > > still only on Hive 1.2.1.) > > I believe Konstantinos' question is about the "bleeding state" of Bigtop > stack. Where all you said is completely true - we don't simply leap forward > and switch a version of a component that is unsupported by the rest of the > ecosystem. > > Yet, our trunk has a number of advances compared to any previous release > and > for some people such deployments might be very desirable. > > Cos > > > ~ Jonathan > > > > On Tue, Jun 7, 2016 at 12:19 AM Konstantinos Tsakalozos < > > [email protected]> wrote: > > > > > Hi everyone, > > > > > > Is there a way to deploy the bleeding edge of the components Bigtop > > > packages? This would greatly benefit Apache project developers as well > as > > > users that want to try out the latest features. > > > > > > Do we have a mirror with deb packages nightly builds that install what > is > > > on the head of the Apache projects offered by Bigtop? We would also > need to > > > grab the head of Bigtop on github, right? > > > > > > Thank you, > > > Konstantinos > > > >
