Hi, On Fri, Aug 21, 2026 at 2:49 PM Emond Papegaaij <[email protected]> wrote:
> Op vr 21 aug 2026 om 18:12 schreef Ernesto Reinaldo Barreiro < > [email protected]>: > > > 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. > Then you force people to move on, which is fine if you ensure a good level of backwards compatibility (a company can afford to spend a week migrating once per year). Not every 3 months > > > 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?\ > I don't mean this person will be the only contributor. This person doesn't need to be the main contributor, but he/she could coordinate everything. 1) Ensure PRs are reviewed (ping people who might know about the subject). 2) Handle releases. 3) Security issues (assigning them, monitoring and so on),4) social media. This should be a daily job, as it is for any other company. If the person doesn't perform, then we look for a replacement. I do not know how to legally handle this—who should hire this person and so on—but maybe several companies could agree to cover the expenses together. E.g. Perhaps one company could hire this person (e.g. an external contractor) and that company could then invoice the other participating companies for services provided by this contractor. E.g. Company A hires this person. Company B agrees, "I will pay 1000 euros per month for this person." Then Company A invoices Company B for this amount. I have no idea if this would be possible or how many companies could participate. I know my customer mentioned this as one of the possibilities to keep Wicket "alive". > > > 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. > Clear. My company (customer) is also considering moving in the same direction. > > > 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. > As a rule, I try to port everything custom I do to Wicket (e.g., uploading to a resource I created for my customer). Once this worked internally, I ported it to Wicket. Fortunately, my customer agrees to let me contribute back to Wicket. > > > 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. > More than breaking APIs I'm concerned about untested changes in behavior. That's why I think the only way to switch to what you describe is to have very high test coverage. Some of the things I contributed we test internally (e.g., we use Selenium against our app), but they aren't covered by tests in Wicket. We are also up to date with many libraries, in particular, we are always using the latest released Wicket and satellite projects. Before approving any Wicket release, I ensure our application works with the version to be released (part manually and part via many tests). -- Regards - Ernesto Reinaldo Barreiro Apache Wicket Committer Emerging artist https://www.instagram.com/reinaldo.barreiro.art/
