I think that an API change is neccessary and that ist is just the right
point of time to do it. Most of the projects based on wicket are not
very old, therefore good enogh in mind of the developers to perform an
api change. Some of them (the new component constructor) can be handled
by an
On 8/25/06, Stefan Lindner [EMAIL PROTECTED] wrote:
BUT: where can I get wicket 2.0? The official link to SVN on thesourceforge page points to http://svn.sourceforge.net/wicket. And e.g.in trunk, the project.xml file still has
1.2-SNAPSHOT as the curretnversion.Oh, you're right but that
Wicket 2.0 is in trunk. Might very well be that the project files are
not up-to-date though. Wicket 2.0 is easy to recognize as instead of
calling add on parents, you now pass the parent in the constructor of
components.
Eelco
On 8/24/06, Stefan Lindner [EMAIL PROTECTED] wrote:
I think that an
An: wicket-user@lists.sourceforge.net
Betreff: Re: [Wicket-user] Wicket 2.0, when?
Wicket 2.0 is in trunk. Might very well be that the project
files are not up-to-date though. Wicket 2.0 is easy to
recognize as instead of calling add on parents, you now pass
the parent in the constructor
Hillenius Gesendet: Freitag, 25. August 2006 08:28
An: wicket-user@lists.sourceforge.net Betreff: Re: [Wicket-user] Wicket 2.0, when? Wicket 2.0 is in trunk. Might very well be that the project
files are not up-to-date though. Wicket 2.0 is easy to recognize as instead of calling add on parents, you now
-user] Wicket 2.0, when? Wicket 2.0 is in trunk. Might very well be that the project
files are not up-to-date though. Wicket 2.0 is easy to recognize as instead of calling add on parents, you now pass the parent in the constructor of components. Eelco
PROTECTED]
Subject: Re: [Wicket-user] Wicket 2.0, when?
To: wicket-user@lists.sourceforge.net
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
then it has to be automated. Because if it is constant a manual thing
then
it cost us to much work.
But we could throw
--
Message: 1
Date: Fri, 25 Aug 2006 11:09:06 +0200
From: Johan Compagner [EMAIL PROTECTED]
Subject: Re: [Wicket-user] Wicket 2.0, when?
To: wicket-user@lists.sourceforge.net
Message-ID:
[EMAIL PROTECTED]
Content-Type
at this time This would be a helpful Johan! I think this would be a good kick off for
Wicket 2.0. Stefan -- Message: 1 Date: Fri, 25 Aug 2006 11:09:06 +0200 From: Johan Compagner
[EMAIL PROTECTED] Subject: Re: [Wicket-user] Wicket
--
Message: 1
Date: Fri, 25 Aug 2006 11:09:06 +0200
From: Johan Compagner [EMAIL PROTECTED]
Subject: Re: [Wicket-user] Wicket 2.0, when?
To: wicket-user@lists.sourceforge.net
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
when will your product be released?wicket 2.0 will change here and there. But not to much i think.So if you start a new project and can live with some api changes on the road and you don't have to release within 2 or 3 months then wicket
2.0 will be a right choice.johanOn 8/24/06, Otan [EMAIL
I think 2.0 will still be out for a month or 3-4. It depends on what
features we find missing, what works and not, and how many bugs need
to be solved from the moment we hit beta. It would be a drag for 2.0
to be half baked so to speak, requiring another API overhaul in a
couple of months.
The
Martijn Dashorst wrote:
The API will change constantly, but not dramatically. i.e. I seriously
doubt that *all* components will have to change again. But some minor
things are bound to change.
I hope the changes will be mostly compatible, if not fully. API changes
is what drove me away
it also explains why java gets its feature improvements at such a snail pace, and why generics/autoboxing are so horribly half baked (imho of course). if you are looking for stability then dont cross the major version threshold. eg we will never horribly break api between
1.2 and 1.3. our primary
On Thu, 2006-08-24 at 20:15 +0200, Erik Brakkee wrote:
Can't wicket use the approach followed by SUN which is never to change
an interface in a downward incompatible way but instead to add new APIs
and make old ones deprecated or extend them? I believe SUN would have
been completely out of
Igor Vaynberg wrote:
it also explains why java gets its feature improvements at such a
snail pace, and why generics/autoboxing are so horribly half baked
(imho of course). if you are looking for stability then dont cross the
major version threshold. eg we will never horribly break api between
16 matches
Mail list logo
