Hi, Op zo 23 aug 2026 om 19:07 schreef Johan Stuyts via dev < [email protected]>:
> > > [...] 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. > > No problem. Like I said: if it is needed, it is needed. > > I was commenting on allowing (many?) breaking changes on a regular > schedule. I know OpenRewrite helps, but I think that being absolutely sure > a Wicket upgrade did not break anything in large applications will remain > expensive. Many behaviors of an application simply do not have automated > tests for them. > Thank you Johan, feedback like this is very valuable. First of all, it highlights the problem Ernesto already mentioned: lack of test coverage. Of course, there's no guarantee that more tests would have caught any regression on this part. But it's hard to move forward without sufficient evidence that everything is still working as intended. It is not easy to increase code coverage with good tests, but it is doable. It is also low risk. You also mention that breaking changes are expensive. I partly agree on that one. It highly depend on how you break. Changes in behavior without compilation changes tend to be more expensive than simple refactors. Take the CSP change as an example. I don't know how your application was affected by this change, but it is very likely that you would have noticed this way sooner if we broke the API like we did for 11. If your application relied on the old callback methods, you may have had some changes in behavior without noticing. In 11 these methods are gone, so you would have seen that right away. This is exactly why I think we should be able to break the API more often than we do now. Backporting changes on an old API is often hard or impossible to get right and it creates the risk of nasty regressions. That still doesn't mean we should break APIs just because we can. In 9 out of 10 cases, it's very easy to add a deprecation warning to the old API and add the new one next to it, giving everyone a smooth upgrade path. I've heard several people already say that companies are worried by the lack of progress on Wicket, and I totally agree. I'm also worried. I also think that the current release schedule (or lack thereof) is holding us back. There's no plan, no timeline, no way of knowing when your contribution will make it into the next release. At the same time, we spend a lot of effort maintaining old branches, which doesn't help either. I don't think there's something like too few new features in a major release. If there was no need to change a single API, then it's a free upgrade. Good for everyone. IMHO what's more important here is the cadence: release a fixed interval on a predetermined schedule. This makes us predictable. At the moment, we release about 5 minors per year (if you only count the latest major). Moving this to 4 releases per year keeps us close to this pace (especially if you count in a few bug fix releases). I still really like Matt's proposal: a major release every 3 months with every 4th release being LTS. This LTS release will get the full year of bug fixes and maybe 3 more months of security fixes. The other 3 major releases do not get any support (optionally we could add in 1 bug fix release for every major a month after its release). So the schedule will look like this: Sep: Wicket 11.0.0 LTS Okt: Wicket 11.0.1 LTS Dec: Wicket 12.0.0 + Wicket 11.0.2 LTS Jan: Wicket 12.0.1 Mar: Wicket 13.0.0 + Wicket 11.0.3 LTS Apr: Wicket 13.0.1 Jun: Wicket 14.0.0 + Wicket 11.0.4 LTS Jul: Wicket 14.0.1 Sep: Wicket 15.0.0 LTS + Wicket 11.0.5 LTS Okt: Wicket 15.0.1 LTS Dec: Wicket 16.0.0 + Wicket 15.0.1 LTS + Wicket 11.0.6 LTS (EOL) Alternatively, we could allow some backporting of new features to the LTS versions, then we'll need to bump the minor number on each release, but the cadence remains the same. What do you think? IMHO this gives everyone what they asked for. LTS versions with 1 year of bugfixing and slightly longer for security updates (to give companies a secure 3 month window to migrate). Frequent releases for anyone that wants to go fast. Not too much hassle with releases an backports all the time (bugfixes only go on 2 branches most of the time). It gives a stable total of about 13 releases per year. This is slightly more than we do now. If we drop the in-between bugfix releases, we go down to 9, which is what we did in 2025. Best regards, Emond >
