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/ >
