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
