In theory, this sounds good to me. Where practical, let's make sure to coordinate with the 2.0 efforts so that we don't overburden our testers or end up with multiple release votes in too quick succession. I don't expect this to happen because all of our release managers are gracious individuals, but it's worth keeping in the back of our mind when it comes to future commitments that we're willing to make.
Mike On Tue, Dec 19, 2017 at 1:53 PM, Andrew Purtell <apurt...@apache.org> wrote: > Greetings HBasers, > > I would like to propose a release timetable for the 1.4 code line as > follows. The below would be what we commit to: > > - December 2017: 1.4.0 > > - Now released! > - January 2018 > : 1.4.1 > - Sweep up changes missed at the 1.4.0 cutoff, especially > > HBASE-19468 > - March 2018 > - End of Q1 2018 > > - June 201 > 8 > - End of Q2 2018 > > - September 2018 > > - End of Q3 2018 > > - December 2018 > > - End of Q4 2018 > > > For these releases we would have approximately the same scrutiny and > analysis afforded the 1.4.0 release. > > In addition we _may_ have more frequent patch releases as necessitated by > critical bug fixes or important changes. > When a critical bug fix is committed we would release immediately. If > there are important changes queued, we'd run a release train at the end of > the current month. These other releases _may not_ be afforded the same > scrutiny as the 1.4.0 release did. > > Sound good? > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
