Creating a Geb 8.0 release

[Jonny <jo...@apache.org>]

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

Re: Creating a Geb 8.0 release

[Carl Marcum <cm...@apache.org>]

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 <cm...@apache.org> 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
>>>

Re: Creating a Geb 8.0 release

[Paul King <pa...@asert.com.au>]

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 <jo...@gmail.com> 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 <cm...@apache.org> 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
> > >
> >
>

Re: Creating a Geb 8.0 release

[Jonny <jo...@gmail.com>]

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 <cm...@apache.org> 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
> >
>

Re: Creating a Geb 8.0 release

[Carl Marcum <cm...@apache.org>]

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
>