Re: Rules on adding classes to a release?
Hi,
(nearly) the same applies to the change in WICKET-2659: Only if you implement
a constructor in a class with signature
public MyErrorPage(final Throwable throwable, final Page page) { ... } this
constructor is chosen instead of MyErrorPage() { ... }.
Best Regards,
Ilja Pavkovic
Am Donnerstag, 22. April 2010, um 19:23:43 schrieb Igor Vaynberg:
> the comment from juergen implies the patch either changes api or the
> way the existing api work. such changes do not make it into 1.4. the
> changes jeremy was referring to would only activate if the cycle
> implemented an interface so it would not change existing
> functionality.
>
> -igor
>
> On Thu, Apr 22, 2010 at 9:18 AM, Ilja Pavkovic
>
> wrote:
> > Hi,
> >
> > applying this rule: why is this change moved to 1.5 ? :
> >
> > https://issues.apache.org/jira/browse/WICKET-2659
> >
> > Best Regards,
> >Ilja Pavkovic
> >
> > Am Mittwoch, 21. April 2010, um 00:06:40 schrieb Igor Vaynberg:
> >> yeah
> >>
> >> -igor
> >>
> >> On Tue, Apr 20, 2010 at 1:49 PM, Jeremy Thomerson
> >>
> >> wrote:
> >> > I forget what our exact rules are for this. I know that we won't
> >> > break API in a point release (i.e. 1.4.8). But, what about the
> >> > following scenarios? I can add these to a point release, right?
> >> >
> >> > 1. Add a class. In this example, I could add a class that is a
> >> > custom subclass of WebRequestCycle that someone can subclass to
> >> > handle runtime exceptions in Ajax differently than they do on regular
> >> > requests. (i.e. they would rather not redirect on an Ajax error, but
> >> > instead would like to send some JS back in a normal Wicket AJAX
> >> > response)
> >> > 2. Add an interface and some associated functionality. In this
> >> > example, I might have an interface to add, and some additional
> >> > functionality that only operated on instances of that interface. No
> >> > functionality would change for existing interfaces.
> >> >
> >> > Those would both be okay, right?
> >> >
> >> > --
> >> > Jeremy Thomerson
> >> > http://www.wickettraining.com
> >
> > --
> > binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
> >
> > +49 · 171 · 9342 465
> >
> > Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
> > Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
--
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
+49 · 171 · 9342 465
Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
Re: Rules on adding classes to a release?
Hi, applying this rule: why is this change moved to 1.5 ? : https://issues.apache.org/jira/browse/WICKET-2659 Best Regards, Ilja Pavkovic Am Mittwoch, 21. April 2010, um 00:06:40 schrieb Igor Vaynberg: > yeah > > -igor > > On Tue, Apr 20, 2010 at 1:49 PM, Jeremy Thomerson > > wrote: > > I forget what our exact rules are for this. I know that we won't break > > API in a point release (i.e. 1.4.8). But, what about the following > > scenarios? I can add these to a point release, right? > > > > 1. Add a class. In this example, I could add a class that is a custom > > subclass of WebRequestCycle that someone can subclass to handle runtime > > exceptions in Ajax differently than they do on regular requests. (i.e. > > they would rather not redirect on an Ajax error, but instead would like > > to send some JS back in a normal Wicket AJAX response) > > 2. Add an interface and some associated functionality. In this > > example, I might have an interface to add, and some additional > > functionality that only operated on instances of that interface. No > > functionality would change for existing interfaces. > > > > Those would both be okay, right? > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com -- binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin +49 · 171 · 9342 465 Handelsregister: HRB 115854 - Amtsgericht Charlottenburg Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
Re: wicket 1.5 build is failing because of 1.6 deps...
Hi,
> that would be weird.
I think the current situation with a deprecated release wicket 2.0 is also
weird. Perhaps the wicket developers should jump over the 2.0 border and
create a 3.0/2.5 (whatever > 2.0 :)) release instead of a 1.5 ?
Best Regards,
Ilja Pavkovic
>
> if wicket 1.3 to wicket 1.4 would be just a .1 increase because of java 4
> to 5
> but because of java 6 we suddenly have to call it wicket 2.0?
>
> purely looking at the java version used wicket 1.3 to 1.4 is a way bigger
> leap then wicket 1.4 to 1.5
> (looking at the changes wicket did for using the new features of java 5)
>
> Ofcourse maybe there are loads of other changes that would recommend a
> bigger version jump
> But the upgrade of a java version from 5 to 6 isnt one of them
>
>
>
> On Tue, Dec 29, 2009 at 12:47, Olivier Croisier
>
> wrote:
> > Then I'd suggest renaming Wicket 1.6 to Wicket 2.0, for the psychological
> > impact, and to state clearly that this is a break in Wicket development.
> >
> > As for Java 1.5 vs 1.6, companies upgraded to 1.5 because it came with a
> > huge lot of new features and improvements that their architects felt
> > could help building better apps & frameworks. On the other hand, Java 1.6
> > is often
> > considered as a mere patch over 1.5 with no real value added, so many
> > companies didn't bother upgrading and are waiting for 1.7 and its new
> > features (closures, etc.).
> > If it were only for me, I'd upgrade to the latest Java version anyday -
> > but this is market reality.
> >
> > On Tue, Dec 29, 2009 at 1:55 AM, Ryan McKinley wrote:
> > >> we can try to avoid it for some time if possible, but if some stuff as
> > >> nicer
> > >> for the core then i am against a separate jar and ugly build system
> > >
> > > +1 for 1.6
> > >
> > > In my opinion, giving people more reasons to use a newer JVM is better
> >
> > (as
> >
> > > if speed were not enough)
> > >
> > > Seems a shame to futz with a strange build to support people who are
> >
> > unable
> >
> > > to upgrade in general. If someone is in an environment where they
> > > can't upgrade JVM from 1.5 -> 1.6 (in late 2010), then seems odd they
> > > are
> >
> > allowed
> >
> > > to upgrade to a new wicket version.
> > >
> > > ryan
>
--
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
+49 · 171 · 9342 465
Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
Re: TeamCity 5.0 upgrade
Hi,
> The teamcity upgrade failed with a database error...
>
> ERROR: function pg_try_advisory_lock(bigint) does not exist
this function was introduced with postgres 8.3. Perhaps you need to upgrade.
Best Regards,
Ilja Pavkovic
--
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
+49 · 171 · 9342 465
Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
