Hi Emond- Thank you for putting this together — yes, this is a great recap!
Some add’l context to share motivations and share some perspective from another Apache project: 1. Providing a ‘heads up’ to users when releases will end being ‘active’ generally keeps the complaints at bay. By announcing this plan, we can start the process to end the support cycle for older release vs hard ending a release when a new one comes out. 2. Wicket is not the first Java-based open source project to start looking to EOL Java 8 and javax.* (non-Jakarta) support. It is becoming increasingly difficult to support JDK 8 and non-Jakarta due to reliance on other 3rd party projects that have all gone inactive or behind a paywall for security fixes (Spring, Jetty, etc). I feel like it is a good time for Wicket to do this as well. 3. We did similar on the ActiveMQ side and the flood gates opened on new contributors. Once ActiveMQ got to a fully modernized dependency stack, we saw 11 new contributors between point releases (v6.2.0 to v6.3.0 release). 4. The one-year trial period gives an escape hatch if the process runs into unforeseen issues, vs calling for a permanent change going forward. 5. SEMVER policy. I think drafting a SEMVER policy would be a good follow-on task (non-blocker). The gap between API and SPI can be blurred in Wicket, and providing some examples will help when breakage can be introduced. For example, in a minor release, we should be able to introduce a new implementation of an interface used internally and not require a major version upgrade. Example roadmap and ‘active’ release branches communication page: These projects have a nice table that shows active releases and the key dependencies in the runtime stack. This has been helpful in communicating roadmap and supported release plans: Apache ActiveMQ: https://activemq.apache.org/components/classic/download/ Apache Karaf: https://karaf.apache.org/download.html Thanks! Matt > On Sep 3, 2026, at 11:14 AM, Emond Papegaaij <[email protected]> wrote: > > Hi all, > > Today Martijn Dashorst, Matt Pavlovich, Jonathan Locke and I had a short > call to discuss our ideas about a renewed release schedule. We discussed > the need for change (both to the current 'schedule' and the code) and the > need for stability (also to both the schedule and the code). We all agreed > that our current way of working is not in the best interest of Wicket and > its community. To move Wicket forward and keep it attractive, we need to be > able to make changes without too much overhead. We also need these changes > to be released in new versions for people to receive them and hopefully > also get some new contributors. However, at the same time we must not > forget that we also have a large existing user base relying on Wicket being > stable and secure. Supporting both groups will require some effort, but if > we do this correctly it should be manageable. > > We therefore propose the following: > * Release Wicket 11 soon, probably somewhere in October. > * At the Wicket 11 release moment, stop supporting Wicket 8 and Wicket 9. > * Starting from that moment, Wicket 10 will only receive security and > critical bug fixes (call it LTS). > * We release a new major version every 3 months from that moment onward. > * We support Wicket 10 until Wicket 14, our next LTS. > * After 1 year, we evaluate this process and adjust if needed. > > We believe this will bring stability, the possibility to improve and > predictability to Wicket. We should announce this on the announce list well > in advance of the Wicket 11 release date, to give our users a chance to > react before we do anything. What do you all think? Martijn, Matt and > Jonathan, do you agree on my summary of the call? > > Emond > > Op di 25 aug 2026 om 17:22 schreef Ernesto Reinaldo Barreiro < > [email protected]>: > >> Hi, >> >> On Tue, Aug 25, 2026 at 4:37 AM Andrea Del Bene <[email protected]> >> wrote: >> >>> I agree with Martijn on almost everything he said. We deeply need a >>> predictable release policy to keep Wicket alive and kicking and >> attractive. >>> Still have some doubts about the 3 months timeframe,which it might be too >>> ambitious and too "aggressive" for our user base which is mainly >>> enterprise-oriented. >>> >> >> Essentially, I think there are no new users. Just companies with huge easy >> to maintain applications (because of Wicket's DRYness). Thus, I do not see >> the point in a fast paced release schedule. I think users would prefer more >> stable releases and less hassle between them. With the advent of JavaScript >> frameworks, Wicket is very difficult to sell. Thus. I think keeping >> existing users happy is a must. Things like support for Quarkus and so on >> might be nice to have, but only if they are implemented in a way that >> prevents users from suffering backwards compatibility problems. To be >> honest, our company is small and has limited resources mainly dedicated to >> producing and maintaining new functionality for our users. Fighting the >> framework we use is not an option. This might accelerate the decision to >> move to something else... instead of sticking to Wicket. >> >> >>> I also think that, like it or not, we might also need some kind of "API >>> break" policy in order not to stress users too much. But on this last >> point >>> I agree we all don't want to break API for the sake of it and we might >>> proceed through a vote... >>> >>> In the meantime, let's not forget we have Wicket 11 waiting for rolling >> out >>> 😊, we should also decide about a possible timeframe for it's release. >>> >>> "Do something, anything!", Mario Draghi :-) >>> >>> On Mon, 24 Aug 2026, 16:17 Martijn Dashorst, <[email protected] >>> >>> wrote: >>> >>>> I've read the thread and here are my thoughts. >>>> >>>> The point is not to break compatibility every 3 months. The point is >> that >>>> we stop promising that we won't. >>>> >>>> ... >>> >>> >>> >>> Andrea Del Bene. >>> Apache Wicket committer. >>> >> >> >> -- >> Regards - >> Ernesto Reinaldo Barreiro >> Apache Wicket Committer >> Emerging artist >> https://www.instagram.com/reinaldo.barreiro.art/ >>
