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.
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:
http://cwiki.apache.org/confluence/display/WICKET/Backportin
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 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
-
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).
>
> 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
>
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
p
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,
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 sma
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
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 Surve
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 wh
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
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 t
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 Hil
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
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 with
> 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.
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
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 s
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
Ee
> 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
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 Pe
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 di
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 ch
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 (includi
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 1.3
* 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
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
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 c
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. The
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)
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 Su
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
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 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
ive talked some with martijn on irc, what we've tentatively agreed on is
this:
since there is a possibility of introducing big api breaks it is too early
for a beta release.
what we are going to do right now is create a non-public "alpha" release.
(although "checkpoint" is a better name for it).
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).
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 it,
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 constru
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 1.3
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 th
> 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 fina
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 O
44 matches
Mail list logo
