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. 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 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. 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. 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. What do you think? If it's crap, just say so 😉 Do you perhaps have a better idea? Best regards, Emond
