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