I think drafting a version or SEMVER policy would make sense.. doesn’t need to be too crazy but sets the expectation for everyone across all scenarios.
I think with a SEMVER policy and a roadmap, your “what versions do we need?” question is answered definitively. A nice side effect of aligning major dependencies and Jakarta EE is that the Java JDK base version question gets answered as a result IMO something like: Major version releases: - Public API and SPI changes - Major dependency updates (ie. Jetty 11 -> Jetty 12) - Change to default configuration property value - Change of configuration property type (ie. Integer -> Long) - Update to minimum JDK version requirement (ie JDK 11 -> JDK 17) - Update to Jakarta EE specification alignment - New features Minor version releases: - SPI change allowed (should be sparingly) - Minor dependency changes —> Jetty 12.0 -> 12.1 - New components, new implementations of SPIs - Non-breaking new features - Non-breaking configuration flags (no default value changes) - No new required configuration value - No change to JDK required version - No change to Jakarta EE target version - Exception to the above only if security related (ie we need to turn some flag on that was optional or off) Patch version release: - No API or SPI change - No new features or flags - No new configuration properties - No change to configuration default values - No change to configuration type - Security fixes - Bug fixes - Patch and some minor dependency updates > On Aug 21, 2026, at 3:07 PM, Emond Papegaaij <[email protected]> > wrote: > > Op vr 21 aug 2026 om 21:33 schreef Matt Pavlovich <[email protected]>: > >> Hi Emond- >> >> Thanks for starting this thread. I think getting a communicated plan >> around some sort of LTS-like approach is healthy for the community and will >> help with adoption. >> >> Having just gone through similar with Apache ActiveMQ, I feel the pain >> (esp w/ all the security releases!). ActiveMQ just completed our >> ‘modernized’ release at 6.3.x. We used minor releases as we did not need to >> make as many API/SPI breaking changes. ActiveMQ 6.0, 6.1 and 6.2 were >> really short-lived release versions. >> >> 1. I believe major API breaking releases every 3 months is too aggressive, >> and will actually lead to _more_ security patching b/c different groups >> will be on different major versions at different times and all require >> severe security or bug fixes. >> >> 2. Apache Wicket is best for really mature, complicated and long-lasting >> web applications. Expecting those types of applications to migrate every 3 >> mos is really aggressive. >> >> I think a better option may be to work on a _roadmap_ of what to modernize >> (and how). Then there can be non-LTS releases (just like the JDK did) that >> come out every 3-months, break API/SPI, and allow core teams to test and >> validate against POC applications, but not require all teams to upgrade >> core products to align. >> >> Once things level out, a release can be settled on as a long lasting >> ‘active’ branch release w/ security and bug fixes. >> >> For example: >> >> Wicket 11 — non-LTS more lambdas >> Wicket 12 — non-LTS other cool thing >> Wicket 13 — non-LTS more super awesome stuff >> Wicket 14 — LTS stabilized features in 11-13, active for 1 year, bug fixes >> and security, etc >> Wicket 15 — non-LTS next new fancy thing.. >> >> ** We should also do strict Jakarta EE and JDK LTS version alignment as >> part of that roadmap plan >> > > I like this idea. It aligns a lot with my proposal of a new major every 3 > months with 1 LTS version every year, but just puts the emphasis a bit > different. I think this does mean we should not only do security fixes on > the LTS version, but also bugfixes. IMHO that's fine, it's still only 2 > versions to work on: the LTS and the next major, so only 2 targets for > patches. One question I can think of is: do we need another minor release > in between the majors? Something like 11.1. Maybe we can do without, maybe > we can make it optional? With a new major release every 3 months, we are > close to the pace we currently have on the minors. You could argue that if > it currently isn't needed to release more often, that we probably won't > need it either with a different cadence. > > Emond
