Skip to content

Grails Engineering Meeting Notes (12 10 2020)

Puneet Behl edited this page Dec 15, 2020 · 3 revisions

Date: 12/10/2020

Attendees

  • Puneet Behl
  • Jeff Brown
  • James Kleeh
  • Jason Schindler
  • Bobby Warner

Agenda

  • Current Grails Development Activities
  • Transition to GitHub Actions
  • Updates to Grails EOL schedule for 2021
  • Grails release cadence
  • Adoption of semantic versioning
  • Open Discussion

Current Development Activities

Puneet

  • 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

Bobby

  • 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?

Transition to GitHub Actions

  • 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

Grails release cadence

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

Grails "End of Life" schedule for 2021

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

Adoption of Semantic Versioning

  • 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.
Clone this wiki locally