On Tue, Feb 7, 2012 at 5:28 PM, Thomas Singer <[email protected]> wrote:
> It looks like Wicket 1.5 is a so radical change to 1.4 that it better would
> have been named Wicket 2.

The whole request processing part has been rewritten. The whole URL
generation/parsing has been rewritten. But that is the biggest change,
and for the most part internal. *Unless* some more advanced features
were used. For example in our 1200 page, 1M lines of code application
we have overridden Component#newMarkupSourcingStrategy() for a grand
total of 0 times. It appears to me that you have created an
application that is rather tied to the internals of how Wicket works.
And yes, then it is harder to migrate.

> Nevertheless, creating an intermediate version
> which deprecated the old classes and methods but information/code about how
> to migrate to the new API would have MUCH better approach. If 1.4 to 1.5
> requires to rewrite half of the application, I fear for Wicket 2. Maybe it
> will require the use of a different programming language?

Nope. Still Java (but Java 6 at a minimum), and it will not be Wicket
2, but Wicket 6. And you really should join the discussions on dev@ if
you want to have a say in how to evolve Wicket. As of Wicket 6 we'll
be using semantic versioning [1], making it clear that API breaks will
go in X releases rather than in X.Y or X.Y.Z.

Upgrading your application is hard. Keeping Wicket
workable/maintainable is also hard. We strive to balance these things.
We can't predict how hard it is for you to upgrade your application.
We do know how hard it is to upgrade our own applications. And from my
standpoint, I don't like breaking stuff. But I also know that Wicket
needs to evolve, and that with progress comes API breakages.

Not all breakages can be clean where we can keep deprecate old API,
keep that working and introduce new APIs that are better and cleaner.
The Javascript -> JavaScript rename might have been a candidate, but
then going through your code and doing the rename is not too much work
as well.

See the Wicket 6 roadmap [2] for things we are implementing, and the
Wicket 6 migration guide [3] for things we already implemented.
Biggest change: Wicket Ajax is now JQuery based.

Martijn

[1] http://semver.org
[2] https://cwiki.apache.org/confluence/display/WICKET/Wicket+6.0+Roadmap
[3] https://cwiki.apache.org/WICKET/migration-to-wicket-60.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to