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. >>>> >> >>>>
