You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by James Fredley <ja...@apache.org> on 2026/05/20 13:31:03 UTC
[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
Re: [VOTE] Proposal: GitHub release pre-release and latest flags policy for Apache Grails
Posted by Thomas Rasmussen <tb...@apache.org>.
+1 binding
On Wed, May 20, 2026 at 4:08 PM Søren Berg Glasius <so...@glasius.dk>
wrote:
> +1 binding
>
> Den ons. 20. maj 2026 kl. 15.31 skrev James Fredley <
> jamesfredley@apache.org
> >:
>
> > 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.
>
Re: [VOTE] Proposal: GitHub release pre-release and latest flags policy for Apache Grails
Posted by Søren Berg Glasius <so...@glasius.dk>.
+1 binding
Den ons. 20. maj 2026 kl. 15.31 skrev James Fredley <jamesfredley@apache.org
>:
> 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.
Re: [VOTE] Proposal: GitHub release pre-release and latest flags policy for Apache Grails
Posted by James Daugherty via dev <de...@grails.apache.org>.
This appears to be what we spoke about on the weekly and hopefully will
reduce confusion.
+1 binding
On Wed, May 20, 2026 at 9:31 AM James Fredley <ja...@apache.org>
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
>