Op vr 21 aug 2026 om 18:12 schreef Ernesto Reinaldo Barreiro < [email protected]>:
> 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? > That would already help a lot. But the downside is that you force people to upgrade right away when a new major version is released, because you stop patching at that very moment. > 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? > At Topicus we have the same concerns. But you simply cannot rewrite millions of lines of code based on Wicket. That's just too expensive. Personally, I'd rather see several people involved part time as part of their daily job than have 1 full time Wicket maintainer. I think that's a more healthy and sustainable solution. If you put everything on the shoulders of a single person, what happens if that person stops? > 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) > You need good test coverage to get this right. At Topicus we've moved to full AI driven development over the past few months. AI writes the code and a human reviews (often after several AI reviews). My experience is that with good prompts you get really good results. You do need to give it guidelines on some parts, like comments. But on overall a model like Opus 5 produces very high quality code with few errors. The design is up to you. It can help you get it right, but in the end you have to make the real choices. And yes, we cannot go and make large API breaks every 3 months, but I don't think we need to. At the moment we are limited to no API changes whatsoever. Take a look at my recent contribution on page store encryption. I'd love to get that back into our application, but it's 11 only. I did break the API, but I doubt anyone will notice. Most of the external facing APIs stayed the same. > > 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). > Yes, that's exactly what we are also facing and what's actively hindering us in getting things done in Wicket. If you got it working by working around Wicket, why bother fixing Wicket as well and then having to redo your work a third time with the change is released. > 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. > As said above, the fact that we are allowed to break the API does not mean we must. API changes are still intrusive and should be avoided if possible. I do think though that batching API changes over a long time does not make this pain go away. In fact, it often gets worse. At Topicus we upgrade all our dependencies to the latest versions every 2 weeks. Most of the times this includes major versions. We actually spend very little time on these upgrades. If you take a little bit of pain every two weeks, it's much better to deal with than a lot every year. However, I think we are somewhat unique at this. > > > > 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. > > -- > Regards - > Ernesto Reinaldo Barreiro > Apache Wicket Committer > Emerging artist > https://www.instagram.com/reinaldo.barreiro.art/ Emond
