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
