Scott, I know this is disappointing, with all the work you have put in. However, I think this ship has sailed, but there is always the next one.
Some comments on you points below: * Rapid fix is feasible * I can resolve the outstanding SiteMesh 3 issues in two weeks when my schedule frees up. Time has run out and these issues have been on the board for 8+ months. * Risk of a major functional regression * Downgrading to SiteMesh 2 undoes years of improvements and re-introduces bugs that 7.x has already eliminated. Grails 6 is using Sitemesh 2.4.4 and I'm not aware of any bugs. Which bugs are re-introduced? * Breaks the entire 7.x plugin ecosystem * Every plugin released for Grails 7 compiled with this reversion will not be compatible with future releases. This will force developers to have to re-release plugins during the next release cycle further fragmenting the community. This has always been the case, right? Anyway, I think Grails 8 will follow pretty rapidly with other libraries doing major version jumps. * Relies on obsolete, unmaintained code * The proposal pulls in a fork last touched in 2009. Maintaining that branch ourselves means assuming full responsibility for a decade of missing security patches and refactorings. When I look at the project, the 2.4.x branch seems to have had 36 commits and 2 releases with the last 2.4.4 release 2023-08-13. The 2.6.x branch that is continuing this line has had work done in 2024 updating it to Java 17 and migration to Jakarta. * Licensing back-slide * SiteMesh 3 is Apache 2.0. The 2.x codebase is still under the non-standard OpenSymphony license—one of the main reasons we migrated in the first place. Reversion complicates legal compliance for commercial users. The OpenSymphony license seems to be derivative of the Apache License with some additions regarding naming and mentions. * Unrealistic test coverage * Grails 7 has been running SiteMesh 3 for 15 months across thousands of CI cycles. By contrast, SiteMesh 2 would receive very little time testing before a major release—insufficient to surface edge-case failures. I think this is actually the opposite. Some tests seem to have been removed with the upgrade to Sitemesh 3 and some had to be annotated with @Ignore or @PendingFeature until the issues could be resolved, which they have not yet. James' branch is to my knowledge now passing on all reintroduced and previously muted tests. * Wrong 2.x baseline * If we must downgrade, the logical starting point is the actively developed 2.5/2.7 line, not the hastily patched 2.6.0 snapshot. Anything else magnifies technical debt. As I read https://github.com/apache/grails-core/issues/13058#issuecomment-1631552275 the easiest path would be the continuation of 2.4.x which is 2.6.x. Also it seems Grace is using Sitemesh 2.6.x in 2024.0.x. * Opportunity cost * Diverting resources to re-integrate and stabilise SiteMesh 2 moves the project “ten steps backward.” Investing the same effort into fixing the few outstanding issues keeps Grails on a modern, maintained stack and delivers value sooner. I'm not so worried about this, we can always upgrade again later when the integration is ready for it. Den tors 3 juli 2025 kl 18:23 skrev Scott Murphy Heiberg < scottheib...@apache.org>: > -1 Do not proceed because ... > > * Rapid fix is feasible > I can resolve the outstanding SiteMesh 3 issues in two weeks when my > schedule frees up. > > * Risk of a major functional regression > Downgrading to SiteMesh 2 undoes years of improvements and re-introduces > bugs that 7.x has already eliminated. > > * Breaks the entire 7.x plugin ecosystem > Every plugin released for Grails 7 compiled with this reversion will not > be compatible with future releases. This will force developers to have to > re-release plugins during the next release cycle further fragmenting the > community. > > * Relies on obsolete, unmaintained code > The proposal pulls in a fork last touched in 2009. Maintaining that branch > ourselves means assuming full responsibility for a decade of missing > security patches and refactorings. > > * Licensing back-slide > SiteMesh 3 is Apache 2.0. The 2.x codebase is still under the non-standard > OpenSymphony license—one of the main reasons we migrated in the first > place. Reversion complicates legal compliance for commercial users. > > * Unrealistic test coverage > Grails 7 has been running SiteMesh 3 for 15 months across thousands of CI > cycles. By contrast, SiteMesh 2 would receive very little time testing > before a major release—insufficient to surface edge-case failures. > > * Wrong 2.x baseline > If we must downgrade, the logical starting point is the actively developed > 2.5/2.7 line, not the hastily patched 2.6.0 snapshot. Anything else > magnifies technical debt. > > * Opportunity cost > Diverting resources to re-integrate and stabilise SiteMesh 2 moves the > project “ten steps backward.” Investing the same effort into fixing the few > outstanding issues keeps Grails on a modern, maintained stack and delivers > value sooner. > > > On 2025/07/02 15:58:16 James Daugherty wrote: > > Per discussion [1] and the unanimous feedback in the weekly meeting, I'd > > like to propose we revert to Sitemesh 2.x for Grails 7. Please see the > > thread for the reasons, but the initial work is here: > > https://github.com/apache/grails-core/tree/issue14193 The goal would > be > > to revert, and work through any issues as they come up. > > > > The vote is open for the next 72 hours and passes if all binding votes > are > > cast in favor. > > > > [] +1 proceed with the proposal > > [] 0 I don't have a strong opinion about this, but I assume it's ok > > [] -1 Do not proceed because ... > > > > Here is my vote: > > > > +1 (binding) > > > > -James > > > > > > > > [1] https://lists.apache.org/thread/8lynrl0yd6ykn749md1g2wjb8jph3s5l > > >
