I'll start working on that and when I have something to discuss I'll be
back!
Thanks,
Carl
On 8/18/25 9:36 AM, Jonny 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
