It doesn’t really make a lot of sense to release a fix in a 1.12 patch separately without later patches. Doing so would send the confusing message that users need to downgrade to get the fix (or if they upgrade they will lose it).
So, whether we vote separately or not, we should still probably wait to announce all together once all three are ready. --- Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer> On December 2, 2021 at 11:47:28 AM PST, Donal Evans <doev...@vmware.com> wrote: 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?
