I've read the thread and here are my thoughts. The point is not to break compatibility every 3 months. The point is that we stop promising that we won't.
As large consumers of Wicket, Emond and I of course don't like breaking APIs and behaviour. We have to deal with the fallout ourselves. But being too careful also has a cost: we end up seemingly stuck in 2016. And that is a Not Good Place (no relationship to the TV series). I'm still in favour of the core of Emond's original proposal: a planned release every 3 months, patch releases when needed, and no LTS promise. My main problem with LTS is that people will stay on the LTS. And then stay on it some more. They already do that today without us calling anything LTS. If we explicitly designate every fourth release as LTS, I suspect many users will simply treat the three releases in between as preview releases and wait for the next LTS. That gives us frequent releases, but not necessarily frequent adoption. We already have to upgrade because of Java, WildFly, Hibernate, etc. Wicket is just another dependency we need to keep up to date. I'd rather explain to upper management that upgrading Wicket costs a week of senior development time than explain why we keep investing in a framework that doesn't move forward. Wicket is maintained by a very small team, with an even smaller team trying to move it forward. With the onslaught of security issues that we now need to backport to multiple branches because of promises we made in 2014 or so, when we had a larger and more active community, I think we're at a crossroads. An LTS promise effectively transfers the cost of not upgrading from the consumer to the maintainers. And with our current team size, maintaining multiple branches for years is a significant commitment. If a company really needs to stay on an old version for years, there are other options. HeroDevs (not an endorsement, I have no experience nor any relationship with them), for example, provides commercial extended support for old Apache Tapestry versions. Companies can also maintain an old Wicket version themselves or pay someone to do it. No LTS doesn't mean no maintenance. We can still do patch releases when needed. And if we need to make a larger incompatible change, we discuss it. Perhaps support old and new for 2 releases, deprecate first where it makes sense, or use preview APIs for things we're not sure about yet. Stability is great. Ossification is not. I believe that with a regular release schedule and no LTS promise we can still maintain a relatively stable API, while giving ourselves room to move Wicket forward with the small community we have today. Hopefully in a direction that keeps more people using Wicket instead of giving them reasons to move away from it. While this release proposal may look like a revolution, its purpose is evolution: not spending our limited capacity merely maintaining the status quo, but giving Wicket the room to adapt, evolve, and release new features to the community faster than in the past. Martijn Dashorst
