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

Reply via email to