OK, just to be sure here, I can branch for 0.90 now?
> Once I saw the problems in 0.88 I didn't bother to push very hard down
> that direction.
>
> I've now fixed all the problems detected by the new badcode.t
> addition, which checks for $self->method calls where "method" does not
> exists (via Package->can('method')) for that class.
>
> I'm happy to release at pretty much any point, I won't drop anything
> big till it's done.
>
> Adam K
>
> On 14 August 2011 10:25, Peter Lavender <pla...@internode.on.net> wrote:
> >
> > My 2 Ct.: Test and fix as much as possible to release 0.90 as soon as
> > possible (5days sounds good), then start breaking (and fixing) the APIs
> > until we're stable for 0.92.
> >
> >
> >
> > Fine by me.
> >
> > I see a few things have been sorted out, like that tasks test.
> >
> > It actually failed for me during the release process I go through here and
> > reported it in IRC, Adam grabbed it and committed a fix that I tested and it
> > worked again fine.
> >
> > Based on the comments though it did appear to be a problem for some people
> > and not others...
> >
> > However given it's been fixed, and the few other annoying issues with 0.88
> > I'm more than happy to get 0.90 out.
> >
> > It might be worth checking with Adam to see where he got to his reworking of
> > the API's.
> >
> > I'd like to get 0.90 out there and solid to allow time between the next few
> > releases should we need to the time stablise after the API changes.
> >
> > Peter.
> >
> >
> >
> >
> > Gabor Szabo <szab...@gmail.com> schrieb:
> >
> >>On Thu, Aug 11, 2011 at 12:05 PM, Adam Kennedy
> >><adamkennedybac...@gmail.com> wrote:
> >>> Greetings all
> >>>
> >>> With the 0.88 release looking so stable (notwithstanding Sewi's
> >>> issues) my thoughts are starting to turn towards what is left to go
> >>> for 1.00 and what we can do to simplify the job of maintaining
> >>> compatibility for plugins as long as possible after 1.00.
> >>>
> >>> So I'd like to propose a big sweep over the entire codebase, and to
> >>> break as many API things as possible now rather than later.
> >>>
> >>> For example:
> >>>
> >>> Padre does not import constants from Wx because there's simply too
> >>> many, and across hundreds of classes this can add up to 10's of megs
> >>> of ram just for constants.
> >>>
> >>> As a result, we're stuck using the somewhat ugly Wx::wxFOO style
> >>> constants (which also aren't constants since they are AUTOLOAD
> >>> hooked).
> >>>
> >>> I'd like to move to using a naming scheme similar to wxPython and use
> >>> Wx::FOO instead.
> >>>
> >>> While ultimately we need support from Wx.pm for this different style
> >>> of constant, in the short term I've implemented a demonstration you
> >>> can see with
> >>>
> >>> use Padre::Wx ':api2';
> >>>
> >>> This will call all 3000 of the constant functions in Wx and capture
> >>> their values. It then calls constant.pm with all the captured values
> >>> to create "proper" constants with the shorter naming style.
> >>>
> >>> Along similar lines, we have a lot of methods named "on_foo" scattered
> >>> around the API.
> >>>
> >>> I'd like to clean some of these up, so that we only use on_foo_bar for
> >>> handlers which actually catch events directly (i.e. Are passed
> >>> Wx::Event objects) rather than the mix of some having it and some not
> >>> that we have now.
> >>>
> >>
> >>These both seem to be like welcome improvements and I think if we
> >>provide stable releases of Padre with enough time for transition of the
> >>from the old API calls to the new calls (in which time both work) then
> >>it ok to do it now.
> >>
> >>Will we be able to release all that and the fixes of 0.88 in the next 5
> >> days?
> >>
> >>regards
> >> Gabor
> >>_______________________________________________
> >>Padre-dev mailing list
> >>Padre-dev@perlide.org
> >>http://mail.perlide.org/mailman/listinfo/padre-dev
> > _______________________________________________
> > Padre-dev mailing list
> > Padre-dev@perlide.org
> > http://mail.perlide.org/mailman/listinfo/padre-dev
> >
> >
> > _______________________________________________
> > Padre-dev mailing list
> > Padre-dev@perlide.org
> > http://mail.perlide.org/mailman/listinfo/padre-dev
> >
> >
> _______________________________________________
> Padre-dev mailing list
> Padre-dev@perlide.org
> http://mail.perlide.org/mailman/listinfo/padre-dev
_______________________________________________
Padre-dev mailing list
Padre-dev@perlide.org
http://mail.perlide.org/mailman/listinfo/padre-dev
