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 Thanks! Matt Pavlovich > On Aug 21, 2026, at 11:10 AM, Ernesto Reinaldo Barreiro <[email protected]> > wrote: > > Hi, > > On Fri, Aug 21, 2026 at 9:18 AM Emond Papegaaij <[email protected]> > wrote: > >> Hi all, >> >> I was talking to Martijn Dashorst today discussing the future of Wicket >> development and we both got the feeling that the current release schedule >> no longer works well for us. I would therefore like to start a discussion >> on changing our release schedule and guidelines on supported versions. >> >> The first observation we made was that the high volume of LLM generated >> security issues is putting quite a strain on our not so big team. Dealing >> with these issues consumes quite a bit of time and this complicated by the >> fact that we are still supporting a major release that was cut over 8 years >> ago. For every issue, you have to go back into the history of the project >> to determine which versions are affected, you have to backport the changes >> (which in many cases is far from trivial because the code has drifted quite >> a lot over those 8 years) and then we still have to do the whole release >> process. Every minute spent on these old versions is a minute lost on >> improving the next version. >> > > Maybe just support security fixes for the last released version and > master? > > >> The second observation has to do with how Martijn and I combine our >> professional work with being a committer on Wicket. Our company gives us >> the freedom to work on Wicket in the boss's time, but this freedom only >> goes so far. In the end we have to get our job done. If we could get the >> job done by improving Wicket, that would greatly enhance our ability to >> spend time on Wicket. This does however mean that changes must reach us >> much more quickly via releases than they do now. It's been 2.5 years since >> 10.0.0 was released. Any change made on master since then is still waiting >> for the next release. >> > > The client I work for also allows me some time for wicket and wicket-stuff > but those contributions only happen on 10.x and master. > They are concerned about the lack of activity on the Wicket project and its > future. We have evaluated migrating to other frameworks > but that seems unfeasible because of our project's size and our team size. > They mentioned they might consider > paying (full time) to maintain Wicket. Perhaps several companies could join > this effort and jointly fund someone solely for maintaining Wicket? > > >> >> The third observation is that LLMs allow us to make much larger changes in >> a much higher pace. They allow you to quickly assess new APIs and try new >> things. We can use this to bring Wicket back to the year 2026. Clean up the >> code. Modernize it. Introduce integrations with frameworks that are now >> common and did not exist 10 years ago. These kind of changes require us to >> move fast and not have to wait years for the next release. >> >> > True. But I somehow still feel uneasy trusting too much to AI... Also new > releases need to be backward compatible and I'm not sure we want a new > release every 3 months with a lot of possibly disrupting changes. > This might accelerate Wicket's progress but hamper companies relying on > wicket being stable and backward compatible. IMHO this would be rather > irritating for users. > Something stops working, and you need to find out why, report the issue, > and wait for a new release (or a hot fix release) > > >> Releasing new versions is a labor intensive process. Scripts have to be run >> to tag and build the release. Voting needs to be done. The release needs to >> published. Much of this cannot be automated. The more releases we do, the >> more time is lost on this process. IMHO this means we should go for a >> release cycle that allows us to move fast but does not require us to >> release to many versions per year. >> > > In our case most of the work I do for Wicket and WicketStuff happens like > this: > > 1. We identify a limitation or problem in Wicket > 2. If possible we implement a workaround in our application. > 3. We backport these changes to Wicket and create a "pending" branch (PR) > in our project, adapting the solution to "new Wicket changes". This PR is > on standby, waiting for a new Wicket release > 4. Once a new Wicket release is done we merge this branch. 3 months is a > long time, and our PR will probably become stale, requiring us to spend > time solving conflicts. Not good. > > Thus, frequent releases are good for us. Releases with few changes are most > probably backward compatible (and if not, there are few suspects for why a > behavior is broken). > > >> My proposal is: release a new major version every 3 months and release 1 >> minor in between. We stop supporting any previous version. The latest is >> what you get. We only do extra in-between releases on critical security >> issues that can't wait. If this is too radical, we could make 1 in every 3 >> releases LTS with 1 year security updates (that would give 3 months >> overlap), but with the risk of again having to apply a patch to 3 versions. >> If 3 months is too quick, we could make it 4. I'd rather not go higher as >> that will increase the time to release for new features again. Keep in mind >> that allowing changes in the API every few months doesn't us require to do >> so. Every change to the API should be weighed and preferably have a >> deprecation period. >> > > The question is: which companies will spend time every 3 months to port > their applications to a new major release? > I'm sure my company will not do that... unless a new major release has very > few changes. I do not see any other projects (e.g., Tomcat) having such an > aggressive release schedule. > We already had serious problems migrating to new LTSs, for example, moving > to Tomcat 11 broke Wicket file upload. > We spent considerable time figuring out why, finding a workaround in > Wicket, and finally convincing the Tomcat developers that the problem was > on their end. We really don't want to go through such a pain every 3 months > > I think one major release per year might be okay, provided it is not very > disruptive. Additionally, many of the functionalities I have added are > heavily JavaScript-related, and while we have Selenium tests covering > those, Wicket lacks tests for them. > Thus to me it would be a good idea if we increase our test coverage and > then try to use AI to move forward... in a less aggressive manner. > > >> >> What do you think? If it's crap, just say so 😉 Do you perhaps have a >> better idea? >> > > I propose: 1) major LTS release per year 2) every 2 months for the last > LTS, security fixes, and new minor work, and 3) Maintaining only the > current LTS and master (the next LTS). We lack the man-power to do more. > > >> Best regards, >> Emond >> > > > -- > Regards - > Ernesto Reinaldo Barreiro > Apache Wicket Committer > Emerging artist > https://www.instagram.com/reinaldo.barreiro.art/
