Currently I find holding this vote too soon. First we need to let the dust regarding the constructor change settle and make up our mind with that issue. This means holding an actual vote for ditching trunk and let it run for a while. Currently too many discussions are being held at the same time.
So for now I am -1 on this issue, until we have collectively and officially decided what we are going to do with trunk. And for the record, this is a veto, pending the results of an official vote on the constructor change. After that has been decided, we need to recast this vote. Martijn On 3/8/07, Philip A. Chapman <[EMAIL PROTECTED]> wrote:
Guys, I would like to add my non-binding, but whole-hearted agreement with Eelco and Johan. As a 2.0 user, please don't put me through all the pain of either a) backporting, then forwardporting again or b) using an unmaintained codebranch until 1.4 (or whatever) comes out at some unforeseen future. From my standpoint, I took up 2.0 because I liked the changes and because I had faith that 2.0 would be maintained in the future (indeed, it would be THE next big release). Pardon my directness, but If you do this to 2.0, what's to keep you from doing this to 1.4? I appreciate all the hard work and I'm all for your lives becoming easier and wicket becoming better. Just don't forget about us poor 2.0 users in the process, OK? Thanks, On Thu, 2007-03-08 at 08:36 -0800, Eelco Hillenius wrote: I am completely with Johan here: having those last two differences (but big improvements!) merged into 1.3 will save us maintaining an extra branch for a while, it will give the users who are depending on 2.0 a much better upgrade (or downgrade) path, and we'll have a very good 1.3 release without quirks that are in the back of our minds to have to be solved fixed some time. Also, JBQ, besides that there is some hurry for our users, I have the selfish argument that if we are dropping 2.0 (and it looks like we are going to), Martijn and me need to be able to rewrite Wicket In Action fast. We can work around things for a couple of weeks, but not more than that. And let's be realistic, with all the best intentions in the world, it is unlikely 1.4 will happen within say 3 weeks. Of course we have to find some common ground, and I agree that the model change, though 90% of the cases should be easy, might be tricky to change to here and there, and some projects might suffer quite a bit from this. I'm not too worried that the new models aren't stable enough as I think they are sufficiently tried already. Anyway, we should make at least one intermediate 1.3 release without the model change so that people can stabilize on that if they wish (I know I want for my project). I find it unlikely that at this stage we'll have very urgent bugs that will make us have to maintain a branch. So with the idea that 1.3.0beta1 should be good enough to last a while and for people to gather some courage to start on the model change, I *do* think we should merge that change right after the 1.3.0beta1 and just get it over with. Same goes for the validators change probably, though I feel less strong about that personally. So: I feel very strongly about putting the model change in 1.3 after we made a release (this weekend). I can see there can be some pain for people in this, but at the same time, there will be lots of pain for people (like me) if we don't. Eelco On 3/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > because we are dropping 2.0 as un upgrade path > there are numerous reasons to put every feature of 2.0 in 1.3 > > first not to screw the people that do use 2.0 twice > that we drop it and that they have to backport it with nothing not only the > constructor change but also the rest > (and when they have done that going to 1.3 and we release 1.4 they have to > undo there undo's again!) > > secondly if we release that fast as it is now proposed then we go instead of > having > 2 active branches (1.3 and 2.0) and one maintenance (1.2) to > 1 active branche (1.5) and 2 to maintain (1.3 and 1.4) > why are we wanting that? I don't i will not fix over 4 branches gain. Thats > the whole point of dropping 2.0 > > thirdly if we are releasing that quickly we pretty much say to every > 1.3user do upgrade also to > 1.4 > (we really can't do that thats why we have point 2) But if that is the case > then why have 1.3? What is that > 1.3 release? Its just a quickly intermediate build. > > I could go on for some more time and point out a few extra points why i > really don't like the current proposal. > Its just more work for everybody in the long run, for our users and for our > selfs. > > johan > > > On 3/8/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote: > > > > * Igor Vaynberg: > > > > > THIS VOTE NEEDS TO GO ON USER LIST > > > > Please Igor and Johan, > > > > Many important things are currently discussed, it becomes very > > confusing for both the developers and the users to follow. Can we > > slow down the rate at which new proposals are raised, and at least > > agree on wicket-dev before proposing something on wicket-user? I > > don't think it's a good idea to ask users opinion when we > > don't have a clear understanding for this ourselves. > > > > Of course we will backport this feature if a majority of people > > think it's good, but maybe not *right now*. We have enough things > > to deal with ATM. Get a release out first, then merge the > > features we want from trunk *progressively*. There's no hurry. > > > > And Johan, what do you call 1.3 by the way? Is it the release > > that we are all expecting since months? In this case I follow > > AlMaw's opinion, please let the dust settle and do it in a few > > weeks. > > -- > > Jean-Baptiste Quenot > > aka John Banana Qwerty > > http://caraldi.com/jbq/ > > > -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
-- 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
