I agree, I think we discussed it before and the Kafka upgrade doesn't belong in 41
Sent from my iPhone > On Dec 18, 2015, at 23:26, Sean Busbey <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>>>> [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>>>>>> >>>>>>>>> s/features/buxfixes/ >>>>>>>>>> >>>>>>>>>> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc <[email protected]> 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 >
