No question about it.
But with 1.2 people have quite some things to do now. To get it running, it is doable just fine.
I had hoped that after 1.2 the api pretty much stabelized (there is my compartibility!)
But now if we do that refactor after 1.2 we again have developers do quite some code refactor...
I still don't like that.
If you don't want .x release to be broken. (for me also the case! don't have a discussion here) then we shouldn't call 1.2 1.2..
But directly call it 2.0 and do the refactor for parents in constructor of child and be done with it.
Or have a Really Really small window between 1.2 and 2.0 and we then Have to keep 2 branches i think
Because anybody moving to 1.2 expect maintenance on 2.0 because he says you broke again that and this. So it is a lot of work
The base thing is how longer we work how more difficult it will be come for many developers..
About youre point.
Do we have a lot of usecases that that is the case?
And would it be so bad that you first create the page and then add the panel? instead of calling directly the constructor of the page with the panel?
I thought you did Windows MFC or something if i can remember correctly?
Last i know almost all native gui libs has this paradigm. that childs need directly the parent. Only Swing and AWT (because of the peer nature don't)
johan
On 1/17/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
You can't be serious about that... I find the problem that Ari has very important. As I mentioned earlier, I think we should take backwards compatibility very, very seriously. That means not breaking stuff between .x releases. Only when we don't get negative votes, I could envision doing an API breaking thing.
On a side note, I think we should contemplate the constructor based variant before we commit ourselves to it.
I can't give a Panel instance as a parameter to a Page constructor anymore in the new setup. Was this already thought of? For instance:
Panel panel = new BarPanel(someSpecialModel);
Page foo = new FooPage(panel);
setResponsePage(page);
MartijnOn 1/17/06, Johan Compagner <[EMAIL PROTECTED]> wrote:i don't get this.
Then we accumilate MANY MANY more people like that having those problems when we release 2.0!
Or is the idea..
Release 1.2 for example first of februari and then the 10th of februari we have 2.0??
because if 2.0 cost only one or 2 months after 1.2 we have a much bigger problem with everybody who is
on the 1.2 train.
i still think now is better.
Break now "everything" and then be done with it.
johanOn 1/17/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:Yeah. Fair enough. +1 for 2.0 then. But let's not wait too long with
releasing 1.2. I think we should finish the session/ pagemap
refactorings that have been going on, and do a last scan through the
issues and then release 1.2. and go into maintenance mode for that
release. And start right away with 2.0 after that.
Eelco
On 1/17/06, Janne Hietamäki < [EMAIL PROTECTED] > wrote:
> Sounds reasonable. Breaking this on 1.2 would cause too much trouble to
> the users.
>
> So, +1 for 2.0
>
> Martijn Dashorst wrote:
> > +1 with Jonathan.
> >
> >
> > On 1/17/06, *Jonathan Locke* <[EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]>> wrote:
> >
> >
> > i can understand this predicament and this was my first suggestion:
> > that we release 1.2 as-is and then quickly release a 2.0 with these
> > constructor changes before focusing on a longer-term 2.1... i think
> > your request is a reasonable one and since you object, i'd like to
> > change my vote to match yours.
> >
> > -1 for 1.2
> > +1 for 2.0 (on a very quick release cycle after 1.2)
> >
>
> --
> Janne Hietamäki
> Cemron Ltd
> http://www.cemron.com/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
