Before we start a vote for renaming our package structure, I think we should carefully consider the consequences.
The proposal is to rename our wicket.* package to org.apache.wicket.* There is no requirement within Apache to do so, but it can/will save some discussions on general@ and later on in our live as Apache project If I remember correctly the idea was to rename the package structure only for wicket 2.0, as this version already breaks API compatibility. Now the problem comes with keeping both 1.3 and 2.0 in sync. Bugs found or new features in 2.0 can (with some effort) be backported fairly easy and vice versa. When we change the package structure to org.apache.wicket, it will be a lot harder to apply a patch between the two branches. So how should we go about this? We could *not* move, and keep the package the way it currently is. We could move both 1.3 and 2.0 before the first release to org.apache.wicket, breaking the api for 1.3 considerably, but in a very predictable manner. We could even supply a refactor script for this. We could only move 2.0, and only just before our first public developer release. What do you think? Martijn -- <a href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote</a> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket</a> at the <a href="http://www.thebeststuffintheworld.com/";>Best Stuff in the World!</a>
