A couple of inline comments but thanks for the pointers. I went ahead without making changes for the current releases. :-)
On Sat, Feb 4, 2023 at 1:31 AM Andres Almiray <aalmi...@gmail.com> wrote: > Thanks Paul, > > I guess I'll have to create a map of tasks, their dependencies, and their > behavior to have a better understanding of the release process. > > I can see that files are uploaded to an Artifactory instance > - https://jreleaser.org/guide/latest/reference/upload/artifactory.html > for Zips > - > https://jreleaser.org/guide/latest/reference/deploy/maven/artifactory.html > for JARs, POMs > > Files are downloaded from Artifactory to later be synced to Maven Central > Later Groovy versions (4+) are reproducible and so shouldn't need this double handling but the release scripts currently cater for both. > - https://jreleaser.org/guide/latest/reference/download/http.html > download files > - https://jreleaser.org/guide/latest/reference/deploy/maven/nexus2.html > deploy to MC. Status for close and release operations are polled > automatically > Do you know whether after the release operation succeeds whether further syncing/caching occurs before artifacts might actually show up? > Release notes are populated with information provided by Jira. JReleaser > doesn't offer this kind of integration yet, but it could do so in the > future. > > Cheers, > Andres > > ------------------------------------------- > Java Champion; Groovy Enthusiast > https://andresalmiray.com > https://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, > and those who don't. > To understand recursion, we must first understand recursion. > > > On Thu, Feb 2, 2023 at 12:57 AM Paul King <pa...@asert.com.au> wrote: > >> As long as we use the release manager's Apache email address, the current >> announcer sounds like it will be fine. >> We currently wait until artifacts have synced with Maven Central before >> sending the email. >> Currently that's a manual step. See adhoc.gradle#checkMavenStatus. It >> wouldn't be hard to tweak that though. >> >> On Thu, Feb 2, 2023 at 2:30 AM Andres Almiray <aalmi...@gmail.com> wrote: >> >>> Hi Paul, >>> >>> Great. Thank you for that explanation. Saved me a lot of time searching >>> :D >>> >>> At the moment the SMTP announcer can only configure a single sender, >>> single message, multiple recipients. >>> I could imagine the following scenarios: >>> >>> 1. multiple senders, same message >>> 2. single sender, multiple messages >>> 3. multiple senders, each one with different or shared message >>> >>> Do any of these make sense for Groovy given its current release >>> settings? If so I'd have to add code to JReleaser to support them. >>> >>> Cheers, >>> Andres >>> >>> ------------------------------------------- >>> Java Champion; Groovy Enthusiast >>> https://andresalmiray.com >>> https://www.linkedin.com/in/aalmiray >>> -- >>> What goes up, must come down. Ask any system administrator. >>> There are 10 types of people in the world: Those who understand binary, >>> and those who don't. >>> To understand recursion, we must first understand recursion. >>> >>> >>> On Wed, Feb 1, 2023 at 2:26 PM Paul King <pa...@asert.com.au> wrote: >>> >>>> Hi Andres, >>>> >>>> It's been on my TODO list to incorporate JReleaser where we can but I >>>> haven't found the cycles to date. >>>> Your suggestion is certainly a possibility! >>>> >>>> The release process (two phases to allow for ASF voting) is driven by >>>> the Gradle scripts in: >>>> >>>> https://github.com/apache/groovy-release/ >>>> >>>> These in turn call into the normal build from >>>> https://github.com/apache/groovy as needed. >>>> >>>> So, a PR (or two) could be against either (or both) of these repos. >>>> In some ways it would be nice to drive everything from within the >>>> groovy repo itself >>>> but that isn't a thing for the next release! >>>> >>>> In terms of what happens now, phase2.gradle in the groovy-release repo >>>> has the >>>> announceReleaseOnSDKman task which ultimately triggers the current >>>> tweet from sdkman. >>>> The email is crafted by the proposeAnnouncementEmail task but currently >>>> cut-n-pasted >>>> by the release manager and sometimes adjusted by hand. It is sent to >>>> the Groovy dev, users >>>> and ASF-wide announce mailing lists. >>>> >>>> At the moment, we don't have the credentials for @ApacheGroovy (on >>>> twitter) or >>>> @apachegro...@fosstodon.org as info necessarily needed by release >>>> managers >>>> (though possibly we should). >>>> >>>> Also, in order for the email to the ASF announce mailing list to pass >>>> through moderation, >>>> it needs to be sent from an Apache email address. This isn't part of >>>> the current automation. >>>> >>>> I'm happy to help where I can. >>>> >>>> Cheers, Paul. >>>> >>>> >>>> On Wed, Feb 1, 2023 at 10:48 PM Andres Almiray <aalmi...@gmail.com> >>>> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Though not strictly related to new features, what are your thoughts on >>>>> configuring JReleaser for posting announcements to all supported >>>>> distribution channels? >>>>> The tool can post to Twitter, Mastodon, and send an e-mail via its >>>>> SMTP announcers. >>>>> >>>>> If it makes sense, I can craft a PR which could be tested before the >>>>> next release. >>>>> Or given any time constraints we may test it after the next release :D >>>>> >>>>> Cheers, >>>>> Andres >>>>> >>>>> ------------------------------------------- >>>>> Java Champion; Groovy Enthusiast >>>>> https://andresalmiray.com >>>>> https://www.linkedin.com/in/aalmiray >>>>> -- >>>>> What goes up, must come down. Ask any system administrator. >>>>> There are 10 types of people in the world: Those who understand >>>>> binary, and those who don't. >>>>> To understand recursion, we must first understand recursion. >>>>> >>>>> >>>>> On Wed, Feb 1, 2023 at 1:43 PM Paul King <pa...@asert.com.au> wrote: >>>>> >>>>>> >>>>>> Hi folks, I might try to do a 4.0.9 late this week or early next >>>>>> week. This is mostly to incorporate some OSGi fixes. It turns out all >>>>>> Groovy 4 releases until now have a minor glitch for certain OSGi >>>>>> environments. >>>>>> >>>>>> I might also do a bump on 3_0_X if I have time. >>>>>> >>>>>> It's time to get in any desired fixes or let me know if there are >>>>>> reasons to push this back a little more. >>>>>> >>>>>> Cheers, Paul. >>>>>> >>>>>>
