Hi, I really liked the idea of moving Wicket forward and am ok with the proposed plan.
I would add that I also think this wave of contributions will eventually pass. There is actually a case for it: by January 2010 we had around 2700 tickets in JIRA, during the next 2 years the team actively worked on both maintaining Wicket 1.4 and improving it in the 1.5 branch with major changes which included lots of API changes, internal redesign and new features. By January 2011 we had 3400 tickets and 4370 in the next year, after the 1.5 launch in the second half of 2011. After that the number of new tickets slowed down. At the time, the team wasn't creating a new major 1.5 version every 3 month, but rather new milestones and release candidates every month or two, but looking back it would be amazing if they were major releases ready for use as we are able to create in the moment given both the project maturity and the LLM help. Another difference is that back in 2010 we didn't have LLMs and the work to keep migrating Wicket applications to new major versions is much simpler now. In short, if we create a roadmap of the new major releases for a period of time (say, a year) and backport as much as we can to Wicket 10 during this period. This would be an improvement to how we handled Wicket 1.4 and 1.5. Users would be able to choose to migrate to new major versions during this period or after, where new versions would be created closer to the current model. > [...] Breaking backwards compatibility (unless unavoidable because of security concerns) is terrible. Wicket applications > are usually big, because that is what Wicket was built for. The amount of Wicket code will likely make migrations expensive. > Yesterday I spent an hour trying to figure out why 1 of our CSP tests fell over after upgrading to the latest version. It was because of recent CSP handling changes. Unfortunately the CSP internal change was unavoidable. We did the best we could to keep Wicket 10 working with the same API while backporting the vulnerability fix. Pedro Santos Em sáb., 22 de ago. de 2026 às 15:16, Andrea Del Bene <[email protected]> escreveu: > Just some quick "hot impressions" about this topic > > - I think we all agree we need to adopt a faster, more predictable release > policy that won't make people wait "indefinitely" for a new main release. > After all we are surrounded by good examples (Java in primis) of projects > that benefited from switching to this new kind of policy (better innovation > rate, etc...). So thanks again to Martijn and Emond! > - I also think a 3 months release cycle is too narrow. Don't get me wrong, > I do appreciate the positive energy about this idea, but I don't know > sustainable would be in the long run, both in terms of new ideas and the > effort we would ask to our users to stay up-to-date. I would stay on a more > "safe side" adopting a 6 months windows like already done by other projects > (Java, Ubuntu, etc..). Since Wicket is Java based I think it would be good > following a similar timeline. Just my 2 cents. > - It's funny seeing how we got struck by the same AI-related stress that > happened in other bigger projects :-) , but I guess (and hope) that the > amount of work required by LLM generated > security issues will be much less intense after this first "big new wave" > of contributions... > - About dependencies (required JDK, Jakarta EE, etc...) I think it would be > better if we stick to Java LTS releases, which means change JDK versions > only when a new LTS is out. I don't think most of our users are willing to > adopt the latest Java release unless it's an LTS. > > Andrea. >
