Maybe we can stagger the work by half months? I'd like to give the 2.0 candidates as much time as my own 1.x ones, so it is definitely a consideration I will keep in mind.
> On Dec 19, 2017, at 12:40 PM, Mike Drob <[email protected]> wrote: > > 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 <[email protected]> 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 >>
