+1 binding On Wed, May 20, 2026 at 4:08 PM Søren Berg Glasius <[email protected]> wrote:
> +1 binding > > Den ons. 20. maj 2026 kl. 15.31 skrev James Fredley < > [email protected] > >: > > > 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 > > > > > -- > > Med venlig hilsen, > Søren Berg Glasius > > Hedevej 1, Gl. Rye, 8680 Ry > Mobile: +45 40 44 91 88 > --- Press ESC once to quit - twice to save the changes. >
