Re: [Pythoncard-devel] Fwd: [wxPython-dev] 2.6.2.1 release soon

[Kevin A. <al...@se...>]

On Jan 3, 2006, at 10:14 AM, bra...@om... wrote:

>
> Will requiring wx 2.6 give you freedom to make significant =20
> improvements to PythonCard?
> Does allowing wx2.5.3 hold us back in some significant way? =A0It =
seems =20
> like the requirement
> would introduce a high barrier to entry for beginners on the Mac side, =
=20
> since wx doesn't
> seem to have a good installer for Tiger. Maybe the wx folks will fix =20=

> that issue...

wxPython 2.6.x is supposed to be a stable API so code we do against =20
that shouldn't break in the future as long as people use a 2.6.x =20
release. In wxWidgets, the releases with odd-numbered second digits =20
(2.3.x, 2.5.x, 2.7.x) are considered unstable API releases and can =20
change APIs as well as behavior. The even-numbered releases (2.2.x, =20
2.4.x, 2.6.x) are supposed to be stable, which is why PythonCard 1.0 is =20=

targeted for wxPython 2.6.x.

In practice, wxPython tends to get some new features, API or behavior =20=

changes each release, regardless of whether it is an even-numbered =20
release or not, but 2.6.x is pretty stable and will be the standard for =20=

quite a while. Read the changes to see specifics for the last couple of =20=

releases:

http://starship.python.net/crew/robind/wxPython/daily/20060102/=20
CHANGES.html

For PythonCard, where most of our framework and API issues tend to boil =20=

down to issues with the underlying wxPython/wxWidgets and specific =20
platform, we need to limit the releases we support just so we have a =20
hope of being able to support the code. But making sure everyone is at =20=

least using a reasonable version of wxPython always means there will be =20=

less support problems as everyone has the same bug fixes.

The only reason I didn't want to just automatically push the 0.8.2 =20
requirement to 2.6.2 is that I'm hoping everyone using 0.8.1 will =20
upgrade quickly and we can get more testing before a 0.9 release which =20=

shouldn't be that far away.

Whatever the next big release is before 1.0 I'm pretty certain that =20
will be when we say absolutely no more changes to the framework and =20
resource files will be done that might break code written after that =20
point. For example, if we're going to support tab order separate from =20=

display order, that change has to be incorporated in such a way that =20
older programs still tab as expected without having whatever the new =20
info would be. We definitely will not require wxPython 2.7.x for =20
PythonCard 1.x even though Robin will be working on that pretty soon.

ka

> pyt...@li... wrote on 01/03/2006 =20
> 12:00:52 PM:
>
>  > Robin is planning on a new release this week. The latest test build =
=20
> =A0
>  > info is below.
>  >
>  > Since our releases are supposed to be tracking 2.6.x that means =20
> 0.8.2 =A0
>  > should be changed to require wxPython 2.6.x as a minimum. That =20
> would =A0
>  > mean the default version of wxPython 2.5.3.1 on Tiger would no =20
> longer =A0
>  > be adequate and I suspect a lot of current 0.8.1 users would be =20
> forced =A0
>  > to upgrade wxPython as well. I'm thinking that what we might do =20
> instead =A0
>  > is leave the version check as-is but change the install =20
> instructions =A0
>  > for Python 2.4.2 and wxPython 2.6.2.1. The next release, say =20
> PythonCard =A0
>  > 0.9 we can bump the required version to 2.6.
>  >
>  > What do you think we should do for this release?
>  >=