How did this end - what's the plan? /Anders
Eelco Hillenius wrote:
I didn't mean that bad. I would just prefer someone else to do the next vote.
Eelco
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess sacrasm and frustration dont transfer well over email :|
-igor
On
Hi,
It ended in us agreeing we should get rid of the constructor change.
We currently working on backporting all the 2.0 features to 1.3,
except for the constructor change and the JDK 5 features. You can
track the progress of that here:
Sounds very good!
Generally I try to stay away from beta versions, but in the case of
Wicket 1.4/2.0 I think I'll make an exception.
/Anders
Eelco Hillenius wrote:
Hi,
It ended in us agreeing we should get rid of the constructor change.
We currently working on backporting all the 2.0
On Mar 9, 2007, at 11:33 PM, Eelco Hillenius wrote:
a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including generics).
b)
On Mar 14, 2007, at 9:13 AM, Anders Peterson wrote:
Is the feature set for 1.3 set? I vote to remove everything that may
delay the release of that version.
I think you should take whatever time you need to make 1.3 a full
featured release that won't be obsolete in the near future.
-Ryan
Al Maw wrote
I don't want to do any of A, B or C.
I am not a developer of wicket and it's completely up to yours how you do it,
but why not the following way:
1. Keep Wicket 2 and do the constructor change there. Now you have a java 1.4
branch (wicket 1.x) and a java 5 branch (wicket 2.0 or
The whole gest of the discussion is to remove the constructor change.
It hasn't been decided yet, but the future for the constructor change
seems grim.
Martijn
On 3/14/07, Stefan Lindner [EMAIL PROTECTED] wrote:
Al Maw wrote
I don't want to do any of A, B or C.
I am not a developer of wicket
* Al Maw:
Eelco Hillenius wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
I don't want to do any of A, B or C.
What I /really/ think we should try to achieve:
1. Have long-term JDK 1.4 and JDK 1.5 branches that are easy to
Can anyone vote?
I vote for alternative D.
You asked about reverting the constructor change or not. My
interpretation of the answers you got is: Yes, fine, what ever, but give
us generics (for models at least).
Alternative D is: Revert to working on 1 branch (doesn't matter if it's
called
C as wel.
On 3/10/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not direclty releasing it but usable for people who want 1.3 + java5)
johan
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Can anyone vote?
I vote for alternative D.
You asked about reverting the constructor
Is the feature set for 1.3 set? I vote to remove everything that may
delay the release of that version.
With alternative C; when would you estimate 1.4 (Java5) could be released?
/Anders
Johan Compagner wrote:
1.4 will be java5 (when C is done first)
That we can do pretty quickly.
(not
no there is a discussion about that.
1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0
And no releasing it quickly will not mean that we will release a java5
version quickly
because that will mean we will again have multiply branches to support.
johan
On 3/14/07, Anders
1.3 feature set would be a merge between 2.0 and 1.3 when we drop 2.0
And no releasing it quickly will not mean that we will release a java5
version quickly
because that will mean we will again have multiply branches to support.
It would be my idea to follow up with a Java 5 version asap
Do you plan to still release new features for old Java after you've
released a Java5 version? That seems crazy.
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should have moved to
Java5 at least one year ago!
/Anders
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Do you plan to still release new features for old Java after you've
released a Java5 version? That seems crazy.
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Make one last release for JDK 1.4 and after that it's bug fixing only.
All new development should target Java5. Wicket should have moved to
Java5 at least one year ago!
I beg to
Maintaining Wicket 1.3 should be for bug fixes, not new features. But
that doesn't prevent new components to be developed, or backported by
our community if there is a need for JDK 1.4 components. And if you
really have a need, then you can always use retrotranslator/weaver to
backport 1.5
1) I think you're overestimating the trouble that would cause. The only
thing they're not getting is new features after the next release. In
terms of new (major) releases no one has gotten anything for almost a year.
2) You also lose something by not moving to Java5... Wicket can be
better
isnt this thread a poll? how many polls of the same thing do we need? omfg
ponies!
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Maintaining Wicket 1.3 should be for bug fixes, not new features. But
that doesn't prevent new components to be developed, or backported by
our
This thread is about 'Reverting the constructor change of 2.0', not
about 'Stop supporting JDK 1.5 after 1.3'.
Eelco
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
isnt this thread a poll? how many polls of the same thing do we need? omfg
ponies!
-igor
On 3/14/07, Eelco Hillenius
well obviously we cannot poll for that until we have decided what 1.3 will
be. so first you need a poll on that, then you need a poll that depends on
that poll so we can decide when to drop support for 1.5. and then another
poll on the what to do next, but that poll has to depend on the previous
Don't poll too much - just decide on something. The core development
team is relatively small isn't it... /Anders
Igor Vaynberg wrote:
well obviously we cannot poll for that until we have decided what 1.3
will be. so first you need a poll on that, then you need a poll that
depends on that
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
well obviously we cannot poll for that until we have decided what 1.3 will
be. so first you need a poll on that, then you need a poll that depends on
that poll so we can decide when to drop support for 1.5. and then another
poll on the what to
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Don't poll too much - just decide on something. The core development
team is relatively small isn't it... /Anders
But the user base isn't anymore.
Eelco
-
Take Surveys.
i guess sacrasm and frustration dont transfer well over email :|
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
well obviously we cannot poll for that until we have decided what 1.3will
be. so first you need a poll on that,
From a user base standpoint, I am just waiting for core developer to decide
something...
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Anders Peterson [EMAIL PROTECTED] wrote:
Don't poll too much - just decide on something. The core development
team is relatively small
I didn't mean that bad. I would just prefer someone else to do the next vote.
Eelco
On 3/14/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess sacrasm and frustration dont transfer well over email :|
-igor
On 3/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/14/07, Igor Vaynberg
hi,
i came over from another framework to wicket because i didnt like the
api change with every release there and liked the way wicket does things.
first i was not sure which version of wicket to use and read the mailing
list and found out, that 2.0 suits best to me. after starting 2 bigger
i came over from another framework to wicket because i didnt like the
api change with every release there and liked the way wicket does things.
first i was not sure which version of wicket to use and read the mailing
list and found out, that 2.0 suits best to me. after starting 2 bigger
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
I'm not a committer, but I opt for c.
On Tue, 2007-03-13 at 09:38 -0700, Eelco Hillenius wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
Eelco
-
Take Surveys. Earn
i would opt for (b) but seems im in a minority :)
-igor
On 3/13/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
Eelco
-
Take
I go with crowd, C.
On 3/13/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i would opt for (b) but seems im in a minority :)
-igor
On 3/13/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
Eelco
Eelco Hillenius wrote:
Can I have the opinions of all committers please? Johan is on a skiing
trip but opts for c).
I don't want to do any of A, B or C.
What I /really/ think we should try to achieve:
1. Have long-term JDK 1.4 and JDK 1.5 branches that are easy to
sync/backport from.
I favor (c) as well. A release always takes substantial time so the
fewer the better. In fact, if backporting anything else into 1.3 ends
up being more trouble than anticipated then I vote for rolling it into
1.4 (along with Java5).
Cheers,
Scott
c) as well, except I don't think it's that good idea to release a beta
before that. It certainly ain't beta if we expect the code to change
that significantly. So imho either call it alpha or release it
afterwards we commit the changes.
-Matej
Eelco Hillenius wrote:
Hi,
It looks like the
I didn't have much time in the recent to actually work on apps based
on Wicket, neither 1.x not 2.x. Thus I have no experience wih either
and no preference regarding the constructor change. I go with what the
experts decide.
In 2.x there two more changes which have not yet been backported into
Hi
I am not a committer so I can't really estimate the feasibility of the
various scenarios, but I'd prefer C as it sounds like the fastest road to a
stable release including generics.
Cheers,
Wilko
Eelco Hillenius wrote:
Hi,
It looks like the discussion around reverting the
Hello,
as a purse user of Wicket 1.2, I would like to see option c) happen. I'm
really looking forward on upgrading my current app to use some of the
new features, and to do things more elegantly.
Also, I'd like to see Generics support as soon as possible; IModel makes
so much more sense with
On 10/03/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including generics).
b)
Hi,
It looks like the discussion around reverting the constructor change
that we did for 2.0 has cooled down. This email is not a vote yet, but
a summary of opinions so far[1]. Those of you Wicket committers who
didn't have your say yet (Juergen, Frank, Gwyn, Janne, Jan, Ate), I
consider that an
a) focus on stabilizing 1.3 first, meanwhile keep supporting 2.0
(though only for bugfixes). 1.4 will be the release with backports of
the currently missing 2.0 features, and 1.5 will be 1.4 + the Java 5
features (including generics).
b) as a) but rather than developing 1.3 up to a final
43 matches
Mail list logo
