Yes, voting would be done on the groovy dev mailing list with a [VOTE] email thread.
Cheers, Paul. On Mon, Aug 18, 2025 at 11:38 PM Jonny <[email protected]> wrote: > I haven't started updating the RELEASING.md, though I have been talking > with the Infra team about getting some credentials setup for release > signing. A pull request would definitely be welcome. > > > Is there a plan for whether there will be some milestone Mx releases > prior to RC's similar to how Grails has been working? > > I think we should do an RC, yeah, just to give stakeholders a chance to try > it out and sign off, particularly since it's been a while since the last > release. > > > will we vote on the Groovy dev list or this one? > > I don't have a perfectly clear answer. Given that the Groovy PMC really > needs to sign off on it, I've started thinking we should probably conduct > business on the Groovy mailing list. The "subproject" notion is only hazily > defined at the ASF level, so their support for the workflows doesn't seem > clearly defined for cases like this. That's probably a thing I should nail > down with Paul as to how they want to proceed. > > > On Sat, Aug 16, 2025 at 4:18 PM Carl Marcum <[email protected]> wrote: > > > Hi All, > > > > I see there has been a lot of work done to get Geb ready for a ASF > release. > > > > Is anyone working on updating the RELEASING.md to add changes for ASF > > artifact staging, voting etc.? > > If not, I could begin working on that. > > > > Is there a plan for whether there will be some milestone Mx releases > > prior to RC's similar to how Grails has been working? > > Since the situation is different with Geb being a sub-project, will we > > vote on the Groovy dev list or this one? > > > > Best regards, > > Carl > > > > On 7/7/25 3:56 PM, Jonny wrote: > > > Geb developers, > > > > > > There is consensus that it's time for us to do a release. Folks have > > asked in > > > < > https://groovy-community.slack.com/archives/C2P61JKB7/p1750678779402239 > > > > > > Slack > > > < > https://groovy-community.slack.com/archives/C2P61JKB7/p1750678779402239 > > > > > > and on Github <https://github.com/apache/groovy-geb/discussions/278>. > > > > > > While the Geb project maintains its own mailing list, my assumption is > > that > > > we'll actually need votes from the Groovy PMC, since Geb is a > subproject > > of > > > Groovy. > > > > > > I've been reading through the Apache Release Policy > > > <https://www.apache.org/legal/release-policy.html> and the guide on > > release > > > creation <https://infra.apache.org/release-publishing.html>. I've also > > been > > > reading through the recent thread about the Grails release > > > <https://lists.apache.org/thread/mhl3jqq1d4b39lq45qygkbfz7m5n1br3>. > I'm > > not > > > sure their situation is totally comparable, since Geb is a subproject > of > > > Groovy and Grails is an incubating top-level project. > > > > > > Based on those, I can identify a few things we'll need as logical next > > > steps. > > > > > > First, we'll need to bless one or more people to act as release > managers > > > <https://infra.apache.org/release-publishing.html#releasemanager> for > > Geb. > > > I'm happy to volunteer and get other volunteers who are interested. > Those > > > folks will need permissions to upload artifacts to > > > https://dist.apache.org/repos/dist/release/. My assumption is that > we'd > > put > > > releases under the groovy subfolder. > > > > > > We'll want to review my open pull request > > > <https://github.com/apache/groovy-geb/pull/279>, and either merge it > or > > do > > > something different to accomplish the same ends. > > > > > > The Gradle rat task passes locally, which suggests to me that any > release > > > we create would be valid > > > <https://infra.apache.org/release-publishing.html#valid>. > > > > > > Beyond that, I think the main thing we'll need is some guidance on > > actually > > > cutting the release in an approved way. I would assume that we would > want > > > to build the release from the Jenkins server, so that the artifacts are > > > built on approved hardware. I know that historically Geb releases were > > > mostly done from local machines and would prefer to move beyond that. > > > Likewise, I'd like some guidance on the best way to manage the crypto > > keys > > > for signing releases. > > > > > > Once we get that sorted, we should be able to build an artifact, vote > on > > > its release, and get the release out. > > > > > > Best, > > > > > > Jonny Carter > > > > > >
