I wonder if voting on patch versions makes sense.
Releasing (even patch releases) is an Act of the Apache Software Foundation, and as such there is a legal obligation to follow ASF voting rules for every release. Technically the purpose of the vote is for the Geode PMC to certify that the release meets ASF legal criteria (but there’s never such thing as too much testing, so we also hope reviewers will use the opportunity to think up creative new ways to test each release candidate) --- Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer> On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer <u...@vmware.com> wrote: I wonder if voting on patch versions makes sense. As we should never be breaking any existing features and essentially there should be sufficient testing on the fixes to confirm that they resolve the issues. There should also be no changes to APIs, as those changes should be included in a new minor. I think a bulk announcement makes sense… So where possible we should/could adopt that approach. But bulk vote for releases does not, as each patch version might contain different amount of fixes, for each minor. (some fixes might only be required in older/newer minor versions) From: Owen Nichols <onich...@vmware.com> Date: Friday, December 3, 2021 at 9:56 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] batch patch release voting 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Conichols%40vmware.com%7C96315ce75fc440ed1d8f08d9b5eaf660%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637740843028651711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Yup%2BjajzF9eA5NBSgIREfNJ5PsQyspqfSrxhIkWyqGw%3D&reserved=0> 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?
