And if there is a timeline for support of 7, i.e. ...
# questions
s
And if there is a timeline for support of 7, i.e. when it'll be maintenance and when 8 is planned and EOL's etc that would be useful. I'm assuming that it will be less frequent than a (bi)yearly pre-planned release and will likely be 7 will be the main version until we need 8 and the timeline become more reactive?
j
So a couple points here:
1. Spring changed it's support window. Technically, you can pay broadcom to extend support, but Grails 6 uses Spring Boot 2.x which is end of life unless you pay broadcom. We can do grails releases for grails issues, but since we build on top of Spring we can't patch spring without forking it. If you're looking for CVE fixes for Grails 6, you could pay broadcom and substitute their patched versions in your gradle build. We can do hotfixes for 6, but we've avoided it unless there's a strong community demand. To date, there have been no demands.
2. Concerning 7, 7 is likely going to release in September. For it's support period, we're basically mirroring Spring Boot's open source support period.
There's a ticket somewhere where we documented this, but until we have a firm date of 7's release, we haven't wanted to widely advertise this.
I think 7 is valid until June next year.
Going forward, once 7 is released, the plan is to release when spring boot releases and mirror their release schedule.
s
Awesome... Thanks for this. We obviously would support our apps irrespective of the support windows here, but clients get twitchy with what they deem "unsupported" frameworks etc so this info is really useful.
j
Technically Grails 6 is supported until 7 is released. But because of the upstream dependencies & the move to the ASF, it makes it very hard to do a release.
One of the major changes in Grails 7 is moving to a mono repo & fixing the way we build. Prior to Grails 7, it was almost impossible to release a grails release without having a dependency on snapshot. Grails 7 is a huge leap forward in stability and including only tested, verifiable dependencies.
Here are some example problems we found in the 6 build system: 1. several tests were not running correctly in GORM 2. to do a grails release, we had to do X releases of other projects. This meant it could take upwards of 3 weeks to do a release. 3. the build was not cacheable or lazy. It also had problems running in parallel. 4. because of number 3, final grails releases would often depend on snapshots or release candidates There are numerous other issues, but I did a significant amount of work to get Grails building consistently, reproducible, and to be able to do builds in minutes instead of days ...
There are some major benefits to developers because of those build changes too. For example, running bootRun locally won't force a recompile when there are no changes. The gradle plugins were all modernized to support caching, etc.
and while the RC1 isn't a final release, it's only depending on upstream released dependencies. I'd strongly suggest you use Grails 7, even in RC1, as I feel it's better supported than 6.
It is a full release, that's pinned in time.
s
Technically Grails 6 is supported until 7 is released. But because of the upstream dependencies & the move to the ASF, it makes it very hard to do a release.
Yep. And I understand and suspected just as much. It was merely the lack of any information that caused me to ask. I appreciate you taking the time to answer. We have made a shift internally towards micronaut, but we still have a few legacy systems that need to be supported in Grails 6, so we'll be upgrading to 7 shortly. We have a few modules to upgrade first, which contain extensions to Gorm/Liquibase integration etc so it's not straight forward. We do have only a few dependencies on external modules which have always been the real problems upgrading so hopefully we will see the modules we need have already been upgraded. I've already had conversions with our directors, around us contributing time/money or both to the project given it's a need for us to continue using it, and it was met with an enthused yes. I need to have proper discussions about how we do that with them but I'm hopeful we can try and give back where we can.
I'll add what you have said in regards to SpringBoot internally and not publish it anywhere public. But having the information helps us plan when we should tackle the upgrades too. I did plan on looking at the RC this week but, in typical fashion, everything else is jumping to the forefront of my list. Thanks again.
j
We're hoping to publish most of this information on the release of 7
👌 1
👍🏼 1