-
Notifications
You must be signed in to change notification settings - Fork 949
Grails Engineering Meeting Notes (12 17 2020)
Jason Schindler edited this page Dec 18, 2020
·
2 revisions
Date: 12/17/2020
- Puneet Behl
- David Estes
- Jason Schindler
- Current Grails Development Activities
- Security CVE Update
- Adoption of semantic versioning
- Updates to Grails EOL schedule for 2021
- Open Discussion
- I've been working on releasing Grails and GORM milestone release for 4.1.0.M3
- I've also been working on moving builds from Travis to GitHub Actions
- David: We need to update Grails 3, 4, and 4.1 to address the CVE
- Puneet: The fix has been applied to 4.1 and will be fixed in the next milestone
- Puneet: I need to apply and build the fix for 4.0 and 3.3 and am planning on doing that in the next day or two
-
Puneet: For Grails 3, I'm not sure how to get Travis to build with Java 7
- David: I'm pretty sure you can build with Java 8 on Travis and set the compatibility version to 7
Decision: Grails will start following Semantic Versioning with the next major release
Discussion:
- Jason: Summarized previous discussion about adopting Semantic Versioning starting with the next major release of Grails
- Jason: We will certainly provide an announcement with information about what this means for users. Generally, users should expect a lot more stability between minor versions of Grails and breaking changes should be limited to major releases only.
- David: I believe that Spring uses Semantic versioning now
- David: I also think that Grails is mostly compatible with Semantic Versioning
-
David: I kinda like the pattern the Linux kernel uses where the even numbers are LTS versions
- Puneet: I don't agree with that because then we would need to maintain multiple minor versions of the release as LTS
- Jason: I feel like semantic versioning is something that most developers understand and I would hate to introduce a lot of variation to that
- David: I just think that we should take look at it. It is really close to semantic versioning and has worked out well for us
-
David: I think it should also be announced with a blog post
- Jason: We will certainly do that. Likely right around the beginning of the year.
- David: I also think this will require some updates to the Roadmap. The Grails 5 roadmap may need to be updated.
Updated Decision: We will not schedule EOL for Grails 2 before the end of Q2 2021. We will discuss the schedule for Grails 3 further
Discussion:
- Jason: Summarized discussion from GitHub Teams Discussion
-
David: I agree with Sergio that we should give at least 6 months before EOL
- In the federal space, they require 6 months notice for EOL and it is something of an industry standard
- Puneet: I still feel like Q1 should be the EOL for Grails 2
- David: I'm surprised it isn't EOL yet, but since it isn't I just think people need 6 months notice
- Jason: I don't think that the end of Q2 is unreasonable
- David: I think you are going to end up supporting 3 for a while because there are people that want to stay on Grails 3
-
David: I'm hearing things from developers about not wanting to move to Grails 4. In particular, Groovy compilation can be much slower with Grails 4, Spring Loaded doesn't work for JDKs higher than 8, and some people want to avoid the Micronaut integration
- Puneet: Why do people want to avoid Micronaut?
- David: There is a perception that it will slow down build time
- Jason: There might be some extra time at build but it should come with runtime improvements
- David: For what it is worth, our app is very large and is more stable with Grails 4
- Jason: Do you think that EOL for Grails 3 at the end of Q2 would be seen negatively?
- David: Yes. The developer experience moving from Grails 3 to 4 is not good and until that is better I don't think people will move
- Puneet: I think we can address the Groovy slowness with Paul and see if he has ideas around that
- David: If they could make the Groovy compiler multi-threaded it would speed it up considerably.
- David: The removal of Spring Loaded was a big problem. I understand why Grails wanted to move away from it because Spring wasn't supporting it
- David: I've looked through Spring Loaded and it isn't that complicated but we need someone who understands bytecode to really support it well
- David: There needs to be enough improvements to the developer experience in Grails 4 to help convince people to migrate over
- Puneet: I think we should discuss this further
- Jason: I'll set something up internally and we can use the GitHub discussion over the break to continue the conversation