Proposal: standardize stable release voting periods to 3 days

[Xuanwo]

Current state

The current voting windows for stable releases are not fully aligned:

Release type	Minimum period
Core stable major release	1 week
Core stable minor release	3 days
Core stable patch release	N/A
Stable subproject release	N/A

In practice, the main inconsistency that seems worth addressing is the difference between core major and core minor releases.

Why change this

I think the 7-day window for core major releases is longer than necessary for two reasons:

• Core stable releases already go through an RC process, and often beta or preview validation as well. The final vote is primarily a final confirmation step.
• Our release process is typically planned around a roughly two-week cadence, so a 7-day major release vote materially stretches that cycle.

At the same time, I agree with the feedback that patch releases should remain fast to unblock urgent fixes, and that subproject releases should not be made slower without a stronger reason.

Proposal

I propose that we change only the minimum voting period for core stable major releases, from 1 week to 3 days.

Everything else should remain unchanged:

• Release a new stable minor version of the core project: keep 3 days
• Release a new stable patch version of the core project: keep N/A
• Release a new stable version of subprojects: keep N/A
• the required +1 vote count
• the set of binding voters
• no stable vote requirement for beta / preview releases

If there is support for this narrower proposal, I plan to follow up with a PR that updates the documentation and release discussion automation accordingly.

[westonpace]

I'm in favor of shortening the 7 day limit. I'm not really in favor of increasing the amount of time required for patches.

The current rules are inconsistent, which adds unnecessary overhead for release managers, PMC members, and contributors.

In my opinion this is not a terribly convincing argument. I don't think different release windows for different types of releases is necessarily a problem. It's not clear to me how this adds overhead.

Our release process is typically planned around a roughly two-week cadence. A 7-day vote for major releases materially stretches that cycle.

I agree that this is a problem. The current 7-day limit seems too long.

Release a new stable patch version of the core project: change from N/A to 3 days
Release a new stable version of subprojects: change from N/A to 3 days

I don't really like this change. Being able to release a patch version ASAP is often required. For example, what happens if some transitive dependency releases a breaking change and we need to pin to an older version. I think 3 days is too long for these cases where we need fast turnaround.

[wjones127]

+1 for argument that it's important patch releases don't have a required voting period.

[jackye1995]

I agree that 7 day feels a bit too long. We are releasing major and minor version without any difference, so it makes sense to keep their voting period the same.

I agree with @westonpace that having patch release waiting 3 days seems to defeat the purpose of a patch.

For subproject, I don't know if voting is really meaningful, because it is hard to get meaningful people to review. I think Spark is probably the only one we have more than 3 people to vote, even ray I can only think of 2 people that would really vote it.

[Xuanwo]

Makes sense, will adjust the proposal.

[Xuanwo]

Updated the proposal based on the feedback here.

The revised scope is now narrower:

• change only the minimum voting period for core stable major releases from 1 week to 3 days
• keep core stable minor releases at 3 days
• keep patch and subproject stable releases at N/A

That seems to preserve the fast path for urgent patch releases while still addressing the main issue with the current 7-day major release window.

[Xuanwo]

#6154 has been created, can merge after this proposal been accepted.