A couple of inline comments but thanks for the pointers. I went ahead without making changes for the current releases. :-)
Right. It was too close time-wise to adjust the release process with JReleaser. Once the current release is out we can have another look. Later Groovy versions (4+) are reproducible and so shouldn't need this double handling but the release scripts currently cater for both.
OK. Then any changes to artifact upload procedures have to account for reproducible (4+) and non reproducible (3 & 2) as I’ve seen just a couple of releases posted for the latter. Likely additional security fixes might be needed in the coming years.
Do you know whether after the release operation succeeds whether further syncing/caching occurs before artifacts might actually show up?
AFAICT once a staged repository is closed & released it usually takes about 10 mins for artifacts to become available from the canonical repository. Mirrors and search.maven.org take at least 2hrs to be in sync.
Cheers Andres Sent from my primitive tricorder On 5 Feb 2023, at 23:53, Paul King <pa...@asert.com.au> wrote:
A couple of inline comments but thanks for the pointers. I went ahead without making changes for the current releases. :-) 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
Files are downloaded from Artifactory to later be synced to Maven Central
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.comhttps://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.
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.
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.comhttps://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.
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:
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 (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.
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.comhttps://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.
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.
|
