No, we need to make the case clear and really be sure we don't want to
continue with the constructor change. Too much has been invested into
that project to decide on a whim that we discontinue it. Therefore
discuss it with respect to eachother and the codebase. Ensure our
users are included into the discussion. Ensure we don't leave out
users because they enjoy a skiing trip.
I stress again: this can't be decided before the weekend. It shouldn't.
Yes, I agree. See my other email where I propose some time to let it sink in.
> Like I said earlier, these things go hand in hand. You can't just say,
> we're probably gonna ditch 2.0 without providing an alternative for
> those people working on it. Don't forget *we* have been encouraging
> people to use 2.0 for their long running projects, so arguments like
> 'that's what you got working with beta software' just won't do imo.
We can decide on the future of 2.0 without deciding what we will do
with the features inside. That actually comes after the decision to
discontinue trunk. We really need to separate these discussions.
Otherwise both get diluted.
No we really really cannot separate those things. The only way I am
ever gonna +1 on reverting the constructor change is if I agree with
the transition path for the users who are currently depending on 2.0.
This is not an attempt to do my part of power play. I'm just stating
that it would be unacceptable to me to have an incomplete transition
path and that it is also unacceptable to me to not deliver that soon
once we decided.
We will, if that causes a lot of trouble for people already building
on 1.3. We haven't decided even that trunk is going to be
discontinued. Therefore we don't need the model refactor in 1.3.
That's fine. I'm all for letting the decision about the model back
port being based on whether or not we are going forward with reverting
the constructor change.
Also the change is controversial, at least with Igor and that is for
me reason enough to regret putting it in (right) now.
Yes, but this is not a normal future issue as it is connected to
providing a proper (complete!) migration path in case we decide to
drop 2.0.
No question on the technical merit of the model change, I just don't
think we should decide *now* to include it already. The vote is to
include *NOW*, and that I don't want. I might even not want it in 1.3
final. But that is something I want to discuss after we decide what to
do with trunk, because then it is clear that we need to actually
provide a short migration path.
Like I stated above, it is not something to discuss after we decide on
the constructor change, but rather something to discuss as part of it.
> I want a release first to give people enough stability to do the model
> change when they are ready for it. I *don't* want the model change in
> another branch (after giving it a good thought) as that other branch
> won't happen as soon as it should. Just won't; we have 2.5 years of
> experience with the framework to prove that.
We also have a team that is different for the last half year than the
2 years before that. Different people, different circumstances.
Sure. But putting up branch 1.4 and putting 1.3 in maintenance mode
within 3 or 4 weeks after we decide is just not going to happen. Or do
you disagree with that?
I also think that for people currently on trunk, having 1.4 or 1.5
with generics support will be sooner avaiable than continue trunk
development at its current speed. If we decide to only do (for
example) the model change and generics, I expect us to keep to it.
But see, it is not relevant for the people who are on 2.0, as they are
using those features *today*. They have code that compiles today and
projects they are working on today. They are not working on 2.0 to end
up with 1.4 or 1.5; the only time they would do that is when we decide
to drop 2.0. You can imagine they don't want to rewrite the models and
validators and generics only to put it in at *some* later time *if* we
decide to put these features in.
But the generics in themselves are controversial and may need some extra
development to make them really rock.
I backtrack on the earlier discussion I started. I'm afraid it's all
or nothing with those generics, so give or take a few tweaks, the way
it works in 2.0 would probably be pretty the way it would end up
working for any branch.
So again, I stress: slow down this discussion, make sure we get our
heads clear and get a plan together. Not this frenzy of roadmaps,
votes and other stuff to make a hot headed discussion. First get
1.3-incubating through the ipmc, the rest can be discussed calmly with
respect to each others positions.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
