Yes, which affects when you time getting something into master. Larger
features that are done just before a release (more risk) can get pushed
so that they are committed after a release instead of just before one.
Regular releases ensure the penalty for choosing to get into the next
release aren't too high.
You could make the argument that master should always be in a releasable
state, but I think that even when reviews are done right there is risk
for some features. All I want to note is that a regular release cadence
helps mitigate that risk when we stick to it.
rb
On 12/17/2015 04:32 PM, Tony Kurc 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.
--
Ryan Blue
Software Engineer
Cloudera, Inc.
