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 > > >
