Thanks everyone. Based on this feedback + the PR feedback for the next steps, I'll start this process and open a vote thread soon.
On Mon, Jun 2, 2025 at 12:20 PM Søren Berg Glasius <soe...@glasius.dk> wrote: > @James Daugherty <jdaughe...@jdresources.net> With all the work you have > been and are doing, I am confident that we should move to a vote right > away. > > > > Den man. 2. jun. 2025 kl. 18.11 skrev James Fredley < > jamesfred...@apache.org>: > >> Thank you for all the hard work getting this ready for the vote on the >> first Apache Grails Milestone. >> >> I believe we should call a vote as soon as we can. >> >> James >> >> On 2025/06/01 11:04:21 James Daugherty wrote: >> > Hi Everyone, >> > >> > We gained access to all of the needed credentials in GitHub this past >> > week. I'm happy to report that I've finished the automation steps (up >> to >> > voting). It is now feasible to hold a vote on the M4 if we wanted. >> All of >> > the detailed information is documented in the RELEASE.md in grails-core. >> > At a high level, here's what's been done: >> > >> > 1. Per James Fredley's previous discussion grails-core & grails-forge >> will >> > always release together. This is important because of how our CLI's >> work >> > and the need for the delegating CLI to call either shell or forge. >> > 2. The grails-github-actions have been tested end-to-end (release >> testing >> > was missing previously) & any needed fixes have been applied. >> > 3. The grails publish plugin & associated applications were updated for >> the >> > new signing mechanism. Note: this mechanism uses the local gpg command >> > because a passphrase is not provided for our private key. This does >> mean >> > it takes longer to build / sign our artifacts. >> > 4. grails-core can now build and deploy to a staging repository >> > 5. grails-forge can now build and deploy to a staging repository >> > 6. a source distribution can now be generated after grails-core & >> > grails-forge are staged. >> > 7. binary distributions (wrapper & the cli's) can now be generated after >> > grails-core & grails-forge are staged. >> > 8. Verification of the grails-core jar files, the grails-forge jar >> files, >> > the source distribution, the wrapper binary distribution, the CLI binary >> > distribution, & that the build is reproducible has been fully automated. >> > 9. In the event we need to rebuild, we can now drop the staging >> > repositories and recreate the releases. >> > >> > Here's what's still outstanding: >> > * More reproducible Issues: >> > 1. There is an issue verifying the build across platforms - the mac >> build >> > had javadoc where it picked the wrong class (ConstraintsEvaluator) for >> > method arguments. It appears this is only a problem when duplicate >> classes >> > exist across java & groovy in different packages. (This needs further >> > investigation, but it's not a blocker for this release since we can use >> a >> > container to verify the artifacts) >> > >> > 2. While we fixed the reproducible differences when testing on the same >> > platform, this process found more differences when testing across >> > platforms. I've fixed all of the issues that we have control of, but >> there >> > are 2 groovy issues I've found. >> > a. `@Delegate` reorders methods in the scaffolding project. I've opened >> > https://github.com/apache/groovy/pull/2245 to fix this. >> > b. `@DelegatesTo` reorders its attributes - this impact is most seen on >> the >> > GormEntity trait due to its withCriteria() method. I've fixed this in >> > groovy here: https://github.com/jdaugherty/groovy/tree/delegates-to-fix >> , >> > but I'm not sure if it's the "right" fix. I need Paul's guidance on >> this >> > one. >> > Since both of these are explainable, neither of these changes are >> "needed" >> > for the M4. >> > >> > * Our SVN credentials to upload the artifacts are not working in GitHub >> > Actions. I've opened https://issues.apache.org/jira/browse/INFRA-26876 >> to >> > address this. We can workaround this issue for the release by manually >> > staging the artifacts. >> > >> > * Our release process is spread across several different GitHub >> workflows - >> > instead of being in one. We can't put them in one until we have a way to >> > "delay" running those next steps. We've previously accomplished this >> via >> > the usage of github 'environments'. In the coming week, I intend to >> open >> > an infrastructure ticket to get these environments created, and then >> I'll >> > collapse the workflows so there's one release workflow in `grails-core` >> and >> > one in `grails-forge`. >> > >> > * Paul did an early review of our artifacts and found several >> > compliance issues with ASF policy. I think we've addressed all of the >> > found issues, but we need help from experienced Apache members! We need >> > people to check the source distribution, wrapper binary distribution, >> and >> > cli binary distribution to see if they meet Apache's policies. >> Currently, >> > these artifacts aren't staged to SVN for a vote, but they can be >> downloaded >> > from the M4 pre-release on Github. I hope to follow-up / each out to >> > several members for their assistance on this. >> > >> > * We still don't have our website published or updated to the ASF site. >> > Søren recently agreed to take a look at the website. I'm hoping he has >> > time to help us here. >> > >> > * Mattias has begun work on the Headers & License updates for Grails >> Spring >> > Security. When this work is complete, we'll need to do something >> similar >> > to `grails-core` so we can publish the Grails Spring Security plugins. >> My >> > assumption is we'll hold the Grails 7.0.0-M4 vote prior to this work >> > finishing and have a separate vote for the security plugins. >> > >> > Overall, we could hold a vote and manually perform the remaining steps. >> > Other than getting some people to take an early look at our artifacts >> for >> > Apache compliance, I can't think of a reason to further delay the >> 7.0.0-M4 >> > release. What are people's thoughts on this? Any concerns? >> > >> > Regards, >> > James >> > >> > >> > >> > On Mon, May 19, 2025 at 10:57 AM James Fredley <jamesfred...@apache.org >> > >> > wrote: >> > >> > > We are very close and it has taken a gargantuan amount of effort to >> > > prepare for the first Apache Grails milestone. >> > > >> > > I agreed with the list under "the following needs completed" and think >> > > these two items should be part of that list, for clarification. >> > > >> > > # grails-forge will be staged for release, voted on and released at >> the >> > > same time as grails-core. now required for grails-wrapper, in >> addition >> > > grails-forge-cli (now part of combined shell distribution to SDKman) >> and >> > > start.grails.org >> > > # New grails-quartz and grails-redis plugin milestones will be >> releases, >> > > after grails-core. These two plus grails-spring-security, are the >> three >> > > remaining non-grails-core plugins that moved to ASF. >> > > >> > > Under "some other outstanding item", I do not believe we need to use >> > > 'Apache Grails' in each location that currently says 'Grails'. See >> Groovy >> > > Documentation: >> https://groovy-lang.org/single-page-documentation.html. >> > > That saves us some time. >> > > >> > > https://github.com/apache/grails-static-website/issues - I am glad to >> > > help on the website, I just want to fully understand the end state and >> > > publishing process so we can complete it in one pass and not have to >> rework >> > > it multiple times. >> > > >> > > James >> > > >> > > On 2025/05/17 18:57:10 James Daugherty wrote: >> > > > Hi Everyone, >> > > > >> > > > In the weekly meeting we briefly discussed the outstanding items to >> > > release >> > > > the first Apache milestone: >> > > > https://lists.apache.org/thread/hm3v6ooqqchms81tljk8h2vpvtj1qfcf >> > > > >> > > > I think this discussion merits its own mailing list thread and I'm >> > > > interested to hear everyone's thoughts on the current plans. From >> our >> > > > meeting: we think the current code line now is functional >> end-to-end. We >> > > > now need to determine what should be finished so we can release >> 7.0.0-M4. >> > > > From my notes, the following needs completed to proceed with an >> Apache >> > > > Grails milestone release: >> > > > >> > > > # We will likely wait for Groovy 4.0.27 with Paul's reproducibility >> > > fixes. >> > > > # (assigned to James D) We need to create a script used to verify >> our >> > > > build (so we can satisfy Security's requirements) >> > > > # (assigned to James D) We need to create a gradle script to publish >> > > > the source/jars to the Apache distribution locations. We plan to >> model >> > > > it after the groovy-release repo. >> > > > # (assigned to James D) We need to have GitHub only stage, not >> > > > "release". This requires minor build updates on our side. We >> intend >> > > > to manually release the jars to maven central as part of our voting >> > > > workflow. >> > > > # (assigned to Mattias) spring-security has to be released & headers >> > > added. >> > > > >> > > > I think we have some other outstanding items too, but it's not >> clear to >> > > me >> > > > if they need to be done to perform a release: >> > > > # We need to rebrand "Grails" to "Apache Grails" in our >> documentation. >> > > > # We need to remove references to the Grails Foundation on the >> website >> > > > # We need to deploy the grails.apache.org website. >> > > > >> > > > >> > > > Here's my first attempt at a summary of 7.0.0-M4: >> > > > >> > > > Apache Grails 7.0.0-M4 is the first release for Grails under the >> Apache >> > > > Software Foundation (ASF). This release focuses first on meeting >> the >> > > > requirements of the ASF & improving the developer experience of >> Grails >> > > > itself & Grails Applications. As part of this transition, the >> developers >> > > > moved to a mono repository, reworked the way the various Grails CLIs >> > > work, >> > > > modernized its build system, modernized the various Grails Gradle >> Tasks, >> > > > modernized the various Grails Gradle Plugins, worked towards >> reproducible >> > > > builds, added license headers to our source code, and changed the >> maven >> > > > coordinates of all Grails Artifacts. >> > > > >> > > > Here is the detailed list since 7.0.0-M3: >> > > > * PR #14750 - support non-persistent super classes for >> @Autotimestamp >> > > > * Issue #14745 - remove deprecated doc method on Grails Plugins >> > > > * Issue #14745 - remove duplicate grails.factories & >> grails-plugin.xml >> > > > files now that AST generation is working correctly >> > > > * Issue #14745 - switch to Spring Boot 3.5.0-RC1 with Spring >> Framework >> > > > 6.2.7 due to bug ( >> > > > https://github.com/spring-projects/spring-framework/issues/34796) >> > > > * Issue #14745 - change the grails-gradle-model to export Groovy 3 >> due to >> > > > Gradle Task isolation in later versions of Gradle >> > > > * Issue #14745 - rework the FindMainTask to correctly set the main >> > > > Application class on BootWar, BootJar, & BootRun >> > > > * Issue # 14745 - remove org.grails.plugins.CodecGrailsPlugin; >> > > > use org.grails.plugins.codecs.CodecsGrailsPlugin instead >> > > > * Issue # 14745 - remove the remaining pathingJar task functions >> > > > * Issue # 14745 - fix a databinding scenario in DataBindingUtils to >> > > lookup >> > > > a domain object >> > > > * PR #14749 - retire Mongo 5.0 & 6.0 test pipelines since those >> versions >> > > > are end of support >> > > > * PR #14746 - switch to asset-pipeline-gradle to 5.0.9 >> > > > * PR #14743 - remove redundant buildScript from test projects >> > > > * Issue #14706 - rework grailsw to be usable indepedendently of >> SDKMAN >> > > > installs >> > > > * Issue #14706 - rework grails-shell-cli to be usable independently >> of >> > > > SDKMAN installs >> > > > * Issue #14706 - rework the command cli to support a grailsw that >> can >> > > > self-update either forge or legacy shell cli >> > > > * Issue #14706 - distribute a delegating CLI that can call either >> forge >> > > or >> > > > the legacy shell cli >> > > > * Issue #14706 - rework the legacy shell cli to correctly find >> profiles >> > > > * Issue #14706 - rework both grailsw & grails-shell-cli to be >> testable >> > > > outside of releases >> > > > * Issue #14679 - generate reproducible groovydoc jars >> > > > * Issue #14679 - fix profile compilation to generate reproducible >> jars >> > > > * Issue #14679 - ensure groovydoc is used instead of javadoc for >> > > > documentation jars >> > > > * PR #14709 - switch to Gradle 8.14 >> > > > * PR #14678 - add support for external config locations >> > > > * Refactor grails into a mono repo (grails-views, gsp, data >> mapping, geb, >> > > > etc are all merged into core now) >> > > > * As part of the mono repo transition, several Deprecated classes >> were >> > > > removed from the views project; see the upgrade guide for the >> details. >> > > > * Issue #14679 - refactor grails build to be parallel & lazy >> > > > * Issue #14679 - change all Grails gradle tasks to support Caching >> where >> > > > appropriate and support lazy style configuration >> > > > * Issue #14679 - Redesign the Grails Data TCK to support modern >> versions >> > > of >> > > > Java >> > > > * Issue #14679 - Support consistent property dates in generated >> property >> > > > files when SOURCE_DATE_EPOCH is set >> > > > * Issue #14679 - Make grails.factories generation reproducible >> > > > * Issue #14679 - Refactor Grails AST Transformations to take >> advantage of >> > > > Groovy's TransformWithPriority and enforce transforms always run in >> the >> > > > order defined by the class `GroovyTransformOrder` >> > > > * Issue #14679 - Remove manifest attributes that could vary on the >> Grails >> > > > jars (Built-By, Created-By etc) >> > > > * Issue #14679 - Fix sourcejar creation to not contain duplicates >> > > > * Issue #14679 - Fix javadoc jars to be generated based on >> groovydoc & to >> > > > not contain duplicates >> > > > * Issue #14679 - Change AST transforms to be reproducible by >> adopting >> > > > determined ordering collections >> > > > * Issue #14679 - Configure Grails jars per Gradle's reproducibility >> > > > requirements (fixed permissions, reproducible file order, etc) >> > > > * Issue #13850 - introduce `grails-common` to share common code >> between >> > > > Grails Data Mapping & Grails-Core >> > > > * Issue #14679 - add scripts to confirm reproducibility of Grails; >> > > > currently 14 of 290 jars are reproducible >> > > > * Issue #14679 - make TagLib lookups reproducible >> > > > * PR# 14671 - switch to webjars for test css/js assets instead of >> checked >> > > > in files >> > > > * The Grails Gradle plugin had a bug that caused plugin resolution >> issues >> > > > that was fixed after the last milestone. >> > > > * Rework the grails bom to generate valid Gradle modules, be easier >> to >> > > > maintain, and valid pom files. Enhance the documentation process to >> > > parse >> > > > the bom & generate the published versions in the grails doc. >> > > > >> > > > >> > > > And in addition to all of this: >> > > > * We changed all coordinates of Grails to be org.apache.grails >> based. See >> > > > https://github.com/apache/grails-core/blob/7.0.x/RENAME.md for how >> we >> > > > mapped these libraries. There is also a script documented in the >> upgrade >> > > > guide to assist in upgrading. >> > > > * Significant test fixes >> > > > * Significant documentation updates & changes >> > > > * Addition of license headers to Grails Source >> > > > * Addition of NOTICE to Grails Source >> > > > * Created https://repo.grails.org/grails/restricted/ to replace >> > > > https://repo.grails.org/grails/core longer term. This virtual >> repo's >> > > scope >> > > > is significantly reduced to help reduce the chance of using outdated >> > > > libraries. >> > > > >> > > > >> > > > I'm hoping this recap is a starting point for the release notes of >> > > > 7.0.0-M4. I'm sure I've missed something too. What are people's >> > > thoughts >> > > > on the nexts steps and these notes? >> > > > >> > > > -James >> > > > >> > > >> > >> > > > -- > > Med venlig hilsen, > Søren Berg Glasius > > Hedevej 1, Gl. Rye, 8680 Ry > Mobile: +45 40 44 91 88 > --- Press ESC once to quit - twice to save the changes. >