Completely agree with you on allowing a release if the need is felt. The general release cadence would provide predictability, as you said, but we absolutely should be able to do releases with fixes if we need to. I would suggest we use a numbering of *major.minor* for the regular releases and a *major.minor.revision *for any release outside of that.
On Wed, Sep 7, 2016 at 10:04 AM, Jacques Nadeau <[email protected]> wrote: > I'm +1 for communicating to the user community a particular expected > release cadence. It helps set expectations. I'm +0 on 3 months being what > is communicated. > > I'm -1 on this being a reason to vote down a release proposed by someone. > If a member of the PMC wants to start a release because they perceive a > need, they should be able to. A general release cadence is not a reason to > vote down a release. > > -- > Jacques Nadeau > CTO and Co-Founder, Dremio > > On Tue, Sep 6, 2016 at 5:48 PM, Parth Chandra <[email protected]> wrote: > > > As we discussed in the hangout today, based on the last few releases, it > > looks like a slightly longer time period between releases is probably > > called for. The 1.7 release was almost four months and folks had started > > asking questions about the release while the 1.8 release was done in much > > less time and we found quite a few show stopper issues at the last > minute. > > It seems that a three month cycle is probably appropriate at this time > > since that does not keep folks waiting for a new release and also > provides > > enough time for the team to test things thoroughly before a release. > > > > What does everyone think? > > > > Parth > > >
