On 11/13/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
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?
I'm all for only changes the packages for 2.0. I still would like to
keep the breaks for 1.3 minimal, and generally get it over with asap.
Doing it just before the first public release sounds fine to me.
Eelco
