I would hope that all RCs had been checked thoroughly before any release VOTE occurs.
From: Donal Evans <doev...@vmware.com> Date: Thursday, December 2, 2021 at 11:47 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] batch patch release voting The thing I wonder about with this decision is what happens if there are no problems with two of the releases, but one of them has some showstopping issue that needs to be addressed. Given that not every fix that's going into 1.14.1 is going into 1.12.6, it's possible that an unrelated issue with the 1.14 patch release could hold up the release of the perfectly fine 1.12 release if the vote is on releasing all three. In that case, would there need to be a new RC for the 1.12 and 1.13 releases, given that the vote for them would technically have failed? Would there need to be a new vote on all three releases, or just go ahead with the 1.12 and 1.13 release and re-vote on the 1.14 once the issue is fixed? ________________________________ From: Owen Nichols <onich...@vmware.com> Sent: Wednesday, December 1, 2021 11:45 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: [DISCUSS] batch patch release voting Geode's N-2 support policy can lead to "waves" of patch releases. For example, 1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same fixes in each. Some open source projects group waves of patch releases into a single announcement. It might be nice to do this for Geode. For voting, does anyone have any preference whether to still hold three separate votes, or would it be ok to vote on a batch of patch releases at once? If so, would 3 days still be enough time for the voting deadline?
