On Mon, Feb 6, 2023 at 9:11 AM Andres Almiray <aalmi...@gmail.com> wrote:
> 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. > True, but I anticipate fewer 3 & 2.x releases over time. If we only catered for 4 with JReleaser, that wouldn't be the end of the world. Of course, both scenarios covered is better! :-) > 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. > Yeah, at the moment we wait for them to show up on repo1.maven.org. I don't know if that is the canonical repo or a mirror but probably not an issue in the grand scheme of things. > 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. :-) > > 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 >> > > > >> - 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. >>>>>>> >>>>>>>
