with the Kafka client change backed out for 0.5.0, I'm good to go with 0.4.1 on the rest of the changes.
On Fri, Dec 18, 2015 at 10:11 PM, Joe Witt <joe.w...@gmail.com> wrote: > Sean, > > Yeah i don't disagree with that point. The caveat being it was only a > change to that client not a change to support the new client API and > the behavior with existing clients old and new verified. > > I'd prefer to stick with 0.4.1 and if you still think it is best to > actually just revert that commit and apply it toward 0.5.0. > > What do you think? > > Thanks > Joe > > On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey <bus...@apache.org> wrote: >> Can we update to 0.5.0 instead? The kafka client change isn't >> something I'd expect in a patch release. >> >> On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt <joe.w...@gmail.com> wrote: >>> ok - so master is presently on 041 and it does indeed appear to be all >>> incremental friendly fixes. So looks like we can just use the normal >>> process. As excited as I was to use cherry-pick doesn't look like it >>> is needed. >>> >>> The bugs fixed on 041 so far are all nice cleanup items and things >>> which have been problematic for quite a while. However, there are a >>> few site-to-site issues that would create some pretty annoying issues >>> for users so best to eliminate them. And big thanks to Matt Clarke >>> for finding and reporting them! >>> >>> Gonna prep an RC. >>> >>> Thanks >>> Joe >>> >>> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc <trk...@gmail.com> wrote: >>>> I have no objection to "because we should be able to do this well!" as a >>>> reason. >>>> >>>> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky < >>>> ozhurakou...@hortonworks.com> wrote: >>>> >>>>> Generally RCs are used to address that level of validation, so in the end >>>>> I still think it's a more of a culture one chooses. One common example; >>>>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major >>>>> features. >>>>> >>>>> In any event IMHO the ability to quickly release maintenance releases is >>>>> very important as it showcases our attention to quality >>>>> >>>>> Sent from my iPhone >>>>> >>>>> > On Dec 17, 2015, at 19:32, Tony Kurc <trk...@gmail.com> wrote: >>>>> > >>>>> > I'm not sure I understand "more validation" reasoning - won't features >>>>> > at >>>>> > the end have very little validation? >>>>> > >>>>> >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue <b...@cloudera.com> wrote: >>>>> >> >>>>> >> Another reason to release 0.4.1 is to allow the additions that warrant >>>>> >> 0.5.0 to have more validation before release. With a regular release >>>>> cycle, >>>>> >> features can go in at the beginning to have more time for catching bugs >>>>> in >>>>> >> them. I also agree with what Sean said below. >>>>> >> >>>>> >> rb >>>>> >> >>>>> >>> On 12/17/2015 04:00 PM, Sean Busbey wrote: >>>>> >>> >>>>> >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc <trk...@gmail.com> wrote: >>>>> >>> >>>>> >>> s/features/buxfixes/ >>>>> >>>> >>>>> >>>> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc <trk...@gmail.com> wrote: >>>>> >>>> >>>>> >>>> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0 >>>>> >>>>> features onto 0.4.1? >>>>> >>> This is a good question. >>>>> >>> >>>>> >>> Some downstream users might have different change processes for a >>>>> patch vs >>>>> >>> minor release, so making a 0.4.1 that fixes what we determine to be a >>>>> >>> substantial gap in the 0.4 line would be nice for them. >>>>> >>> >>>>> >>> While we might be a young project now, it would be good to already >>>>> >>> have >>>>> >>> the >>>>> >>> habit practiced for when we have more users in enterprise settings. >>>>> >>> >>>>> >>> On the other hand, 0.4.0 just happened, so a release in 3 days would >>>>> >>> minimize the number of "stuck on 0.4.0" folks. >>>>> >> >>>>> >> -- >>>>> >> Ryan Blue >>>>> >> Software Engineer >>>>> >> Cloudera, Inc. >>>>> >> >>>>> -- Sean
