-
Notifications
You must be signed in to change notification settings - Fork 951
Grails Engineering Meeting Notes (12 10 2020)
Puneet Behl edited this page Dec 15, 2020
·
3 revisions
Date: 12/10/2020
- Puneet Behl
- Jeff Brown
- James Kleeh
- Jason Schindler
- Bobby Warner
- Current Grails Development Activities
- Transition to GitHub Actions
- Updates to Grails EOL schedule for 2021
- Grails release cadence
- Adoption of semantic versioning
- Open Discussion
- 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:
- Major release - Once per year
- Minor release - Every 6 weeks
- Patch release - Every 3 weeks or sooner 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.