Johan Compagner wrote:
> In 2.0 we have a model change:
[...]
> 1> port it to 1.3
>
> 2> don't port it to 1.3
I'm afraid I'm very much -1 on this for 1.3.
I have a bunch of really complex models built using the current 1.3
models, and I expect other people do too.
At the moment, 1.2.x -> 1.3 migration (even for a fairly complex site)
isn't terribly complicated. Putting this in will make it so.
I'd have probably an entire week's worth of rewriting and testing to
update my code (yes, I do have that many complex wrapper models). I just
won't have the time to do that before we want to be releasing beta and
RC builds of 1.3, so I'd suddenly find myself without a nice big complex
app to test against any more. I expect many many people would be in this
situation.
Models are one of the harder things to get your head around in Wicket,
complicated wrapped ones doubly so. Forcing users to suddenly update
large chunks of complex code won't happen - a lot of people will stick
with their current SNAPSHOT 1.3 versions for a while until they have the
time to devote to fixing this. This will mean the beta and RC builds
won't as much testing, which is a really bad idea IMHO.
In my opinion we could, within the next:
-----------------------------------------
1 week - Push 1.3-betas as-is.
2/3 weeks - Bug fix as people test it and push out rc's when
we feel it's solid and stable.
4 weeks - Rename 1.x branch to 1.3.x.
- Release 1.3.0 final and put 1.3.x immediately into
maintenance mode.
- Create 1.4.x branch from 1.3.0 tag.
- Merge the model changes from trunk to 1.4.x.
- Backport anything else from trunk to 1.4.x that's
not JDK5-specific.
6 weeks - Push out 1.4-betas
7/8 weeks - Push out 1.4-rc's
9 weeks - Push out 1.4.0 final
- Create 1.5.x branch from 1.4.0 tag.
- Backport/add generics, covariance and other JDK 5 trunk
features to the 1.5.x branch.
- Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
14+ weeks - Release 1.5.0
Suggestions to make this work:
------------------------------
We won't backport from 1.4.x -> 1.3.x.
We won't actively develop trunk.
We will push 1.4 out very soon after 1.3, and encourage migration.
We will have this in a public roadmap so people can see it coming.
Notes on what you think is insanity, but actually isn't:
--------------------------------------------------------
We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
1.5.x and what's currently trunk). This may seem like madness to you,
but I reckon it isn't:
During 1.3 development, 2.x is low activity, 1.2.x negligible.
During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
During 1.5 development, only 1.4.x will also be quite active.
Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
it may not like being told to migrate to 1.5.x, but that shouldn't be
too hard (much less hard than going from 1.3->2.0) and there shouldn't
be too many of them. I guess that's the price you sometimes pay for
using unreleased software. :-/
I'd envisage 1.4.x will require some backports from 1.5.x. We'd
obviously encourage core developers and patchers to upgrade their sites
to use 1.5.x, do active development on that, and therefore try to only
ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
If you think I'm smoking crack, the above is utterly unreasonable, you
want to kick me out of the gang, or you have any better ideas or
suggestions as to how to keep everyone happy, please shout now. :-)
Best regards,
Alastair
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
