Grails Engineering Meeting Notes (12 10 2020) - grails/grails-core GitHub Wiki

Date: 12/10/2020

Attendees

Working on pushing Grails 4.1.0.M3 out including GORM and Grails Views updates
Since Groovy 3.0.7 is out, I would like to include that as well because it includes the fix for the CVE
After this is done I will push RC and GA releases

Worked a bit on Grails Spring Security plugin trying to get it to 5.4 the plugin currently uses 5.1
- Puneet: Can you also test this with Grails 4.1.0 milestone?

Puneet: I have started migrating GORM for Hibernate to GitHub Actions
- The goal right now is to have the move to GitHub Actions complete for 4.1.0.M3

Decision: We will experiment with the following cadence and adjust as needed:

Discussion:

Puneet: We are planning to try out a 6 week release cadence for minor releases for Grails
James: Should a cadence be set for major or patch releases?
Puneet: We would expect a major release every year. There is no cadence now for patch release
James: We try to get to 2 weeks for patch releases or less if possible on Micronaut. If something comes up and it is important it would be sooner
Jeff: It might not make sense for the Grails releases to be as often as the Micronaut releases. How would you feel about 3 weeks + for patch releases
Puneet: 3 week for patch releases, 6 weeks for minor releases and yearly for major releases
James: Historically when Grails 3.3 came out we were still applying patches to 3.2 but we were not applying patches to 3.1. We kept a one release back maintenance. In order to push the release forward, we need to think about how much time we want to spend doing patch releases
James: In Micronaut, once 2.2 is out, we no longer apply bug fixes in the 2.1 branch and one of the reasons is there should be no breaking changes between 2.1 and 2.2
Jeff: That reinforces the importance of not introducing breaking changes in minor releases

Decision: All Grails releases before Grails 4 will be EOL at the end of Q1 of 2021

Discussion:

Jason: What we would like to propose is: scheduling EOL for Grails 3.0, 3.1, and 3.2 at the end of Q1 of 2021 and EOL for Grails 2 at the end of Q2 2021. The public page would need to be updated with what we decide here.
Puneet: Should be set a date for Grails 3.3 now?
Bobby: There hasn't been any commits to 3.3 since May
Jeff: How would you all feel about EOL for Grails 3.3 at the end of June 2021?
Puneet: Wouldn't that be the same as Grails 2?
Jeff: Are you advocating to put everything at the end of Q2?
Puneet: No, I am saying that maybe we should EOL Grails 2 for the end of Q1
Jeff: How about every release before Grails 4 will be EOL at the end of Q1 of 2021
Group agreed
James: Do you think it would make sense to make a general rule about EOL that would say something about after a year the release will be EOL?
Jeff: I think as we try to adopt a more regular cadence that would make sense. We should formalize that in the webpage
Jeff: What if when a major release comes out, the previous one goes into maintenance mode?
Jason: If we move forward with semantic versioning, I think we should schedule EOL only for major releases since updating to a minor or patch release should not introduce breaking changes for the developer.
Jeff: That simplifies things

Jeff: I think we should have this discussion with a larger group.
Jason: We can move the conversation into GitHub Discussions and start there and then revisit in future meetings as needed.