> > [...] 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. Kind regards, Johan
