Is this for groovy or grails? Groovy currently has tags but not under rel/releases. We'll likely adopt something similar if we move closer to the Grails release process.
On Wed, May 20, 2026 at 10:27 PM James Fredley <[email protected]> wrote: > > 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
