[VOTE] Proposal: GitHub release pre-release and latest flags policy for Apache Grails

Hi everyone,

As part of improving the release experience and visibility on GitHub, I 
am proposing a clear policy for how we manage the pre-release flag and 
the latest release designation on GitHub Releases.

BACKGROUND / RATIONALE

GitHub Releases provide a convenient way for users to discover and 
download artifacts, with features like:
- The pre-release flag (which hides the release from default views and 
affects /releases/latest behavior)
- The ability to explicitly set a release as the latest

During our standard Apache release voting process, it is important that 
un-voted or pre-release artifacts are not presented to users as 
production-ready or as the primary/latest version. This aligns with 
practices used by other Apache projects that publish to GitHub.

PROPOSED POLICY

We adopt the following rules for GitHub Releases associated with Apache 
Grails versions:

1. During vote: Any GitHub release for a version under active vote on 
the dev list must be marked as pre-release.

2. RC and Milestone releases: These are always marked and kept as 
pre-release on GitHub. They must never be set as latest.

3. Stable releases after vote passes: Once a full/stable release vote 
has successfully passed on the dev mailing list, remove the pre-release 
flag from the corresponding GitHub release.

4. Latest designation: Only the highest version full release (non-RC, 
non-milestone, non-pre-release) may be marked as latest on GitHub.
    - Pre-releases, RCs, and milestones must never be marked as latest.

This policy applies whenever we create GitHub Releases. It does not 
change our primary distribution process via dist.apache.org or the 
official download page.

BENEFITS
- Prevents accidental adoption of release candidates or in-flight voted 
releases via GitHub's prominent UI elements and APIs.
- Ensures the latest designation on GitHub accurately reflects only the 
highest officially approved full release.
- Provides clear, consistent guidance for release managers and committers.
- Improves user trust and reduces support burden from users hitting 
pre-releases.

VOTE

Please vote on adopting this policy:

[ ] +1 Yes, adopt the proposed GitHub release flags policy
[ ] +0 Abstain / no strong opinion
[ ] -1 No, do not adopt (please provide reasoning)


The vote will remain open for at least 72 hours from the time of this email.

Thanks in advance for your feedback and votes!

My vote:

+1 Yes, adopt the proposed GitHub release flags policy

Best regards,
James Fredley
Apache Grails

References:
- Apache Voting process: https://www.apache.org/foundation/voting.html
- GitHub Releases documentation: 
https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases