About wxPython 2.5 - proposals

wxPython Users
1

Hi Robin and all wxPython lovers,

The wxPython 2.5 release will be a milestone in the
wxPython series, I mainly think about the introduction of
the "wx package". Some comments and proposals.

i) wxPython relies on Python and wxWindows. wxPython users are
mainly Python users and not wxWindows testers. So the priority
should be set on Python. The actual Python version is 2.3
and it will stay for a long time. KA proposed to drop the
wxPython 2.1 branch. I will go further and I propose to
concentrate wxPython 2.5 solely on Python 2.3. The Python 2.3
changes are quite impressive and have a lot of consequences on
wxPython (depracated apply() function, deprecation warnings on
wrong types, new style classes, encoding, ...). From this mail
list, it seems most users have swithched to Python 2.3. The big
change in Python 2.3 offers the opportunity to make a big change
in wxPython.

ii) Every new wxPython release contains (at least) four things:
bug fixes, new widgets/controls (AnlogClockWindow), new features
(DrawXXXList), updated packages (stc). I think this is too
much at the same time. If you work on a project/application,
and you download a new version, you hope to see corrected bugs
and improved packages. You are not primarly interested in new
stuff.

iii) The point ii) is specially true, for people who develop
3rd-party packages for wxPython.

iv) The first release of wxPython 2.5 should be stamped as alpha
or beta, not 2.5.0 ; (wx.VERSION_STRING is a ...string).
(Downloading trial versions from CVS is too complicate for a lot
of users (including me)). Beside this, there are too many users
that understand 2.5.0 as the "first stable 2.5 version". I think,
the wxPython community (beta testers, not developers) will appreciate
a freezing around a 2.5.0alpha.

v) Any 2.5 documentation should be available on the user's
hard disk.

On my win platform, living with several wxPython versions is
not a problem. Which one to use it's just a question of
directories renaming. I will be very happy to test my apps with
the new wxPython 2.5.alpha and report about bugs.

Jean-Michel Fauth, Switzerland.

2

Jean-Michel Fauth wrote:

I will go further and I propose to
concentrate wxPython 2.5 solely on Python 2.3.

Some of us are stuck with Python 2.2 on Linux. All the features you
talk about work fine on 2.2.

Roger

3

Jean-Michel Fauth wrote:

Hi Robin and all wxPython lovers,

The wxPython 2.5 release will be a milestone in the
wxPython series, I mainly think about the introduction of
the "wx package". Some comments and proposals.

i) wxPython relies on Python and wxWindows. wxPython users are
mainly Python users and not wxWindows testers. So the priority
should be set on Python. The actual Python version is 2.3 and it will stay for a long time. KA proposed to drop the
wxPython 2.1 branch. I will go further and I propose to
concentrate wxPython 2.5 solely on Python 2.3. The Python 2.3
changes are quite impressive and have a lot of consequences on wxPython (depracated apply() function, deprecation warnings on
wrong types, new style classes, encoding, ...). From this mail
list, it seems most users have swithched to Python 2.3. The big
change in Python 2.3 offers the opportunity to make a big change
in wxPython.

Python 2.2.x is the so-called Python-in-a-tie version that is being made rock-solid and is encouraged to be used in corporations, etc. It would be a shame to lock out those users. OTOH, can you name any feature in 2.3 that wxPython should take advantage of that is not also in 2.2?

wxPython in the 2.5 series *will* start taking advantage of some of the features that are in 2.2+ such as the new style classes, properties, etc.

ii) Every new wxPython release contains (at least) four things: bug fixes, new widgets/controls (AnlogClockWindow), new features (DrawXXXList), updated packages (stc). I think this is too
much at the same time. If you work on a project/application,
and you download a new version, you hope to see corrected bugs
and improved packages. You are not primarly interested in new
stuff.

iii) The point ii) is specially true, for people who develop
3rd-party packages for wxPython.

The even-numbered minor releases [major.minor.relese.subrel] are supposed to be API backward compatible (and with 2.4.x they should be unless I make a stupid mistake) *That* is what the 3rd party developers care about. New features and such are easy to ignore until they are needed as long as the APIs don't change.

iv) The first release of wxPython 2.5 should be stamped as alpha
or beta, not 2.5.0 ; (wx.VERSION_STRING is a ...string).
(Downloading trial versions from CVS is too complicate for a lot
of users (including me)). Beside this, there are too many users that understand 2.5.0 as the "first stable 2.5 version". I think,
the wxPython community (beta testers, not developers) will appreciate
a freezing around a 2.5.0alpha.

Join the wxPython-dev list. That is where I make available prerelease versions of the binaries when I start spinning up the release cycle. For example, did you see 2.4.1.0 or 2.4.1.1? The folks on wxPython-dev did and they were able to help identify some last minute problems.

Even so I wish more people took the time to get the CVS version and play with it as that helps discover more problems sooner rather than at the last minute, and it's much easier and less time consuming to apply a patch that fixes a problem than to try and find the problem myself just from a vague description of it.

v) Any 2.5 documentation should be available on the user's
hard disk.

Yep.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Hi,

it's maybe not a good idea to drop support for something that is still
actively used by a lot of people.
A lot of "commercial" users freeze versions, and that is a good thing. If you
maintain a package with a large install base (say 3000 workstations), then
you don't want to switch versions just for the heck of it. Updating something
like that is a very expensive task, so why change it if it's running ?
Quick version changes and short life cycles make larger companies stay away
from open source software. For those customers it's not an option to hear "we
know, the version is just half a year old, but we dropped support for it
since there is a new version now".
For example, I've written a large application that is currently installed on
close to 400 computers thruout California. I can update the software
remotely, however I can't update the dll's remotely (i.e. wxPython, wxWindows
or python itself). To do this I'd have to create an updater (installer) for
several platforms and then I'll have to make sure that everyone actually
updates, because otherwise the next internal update will fail.
Some of them won't download the stuff, so I'd have to burn CD's to send out
etc.etc.etc. Therefor I'll not switch versions just to have python 2.3 where
my software doesn't even rely on.
Besides "upgrading" very often results in errors in the application because
some little thing might have been changed that breaks the application.

I froze versions to 2.2 and wxPyton 2.4.12 - and that's it until I need more
features from later releases, or a bug shows up that needs to be taken care
of and can't be "worked around" in the current release.

(Why buy a fancy sportscar that has no room for my beers, when the old truck
still goes round ? :slight_smile:

Cheers

  UC

···

On Thursday 11 September 2003 09:09 am, Jean-Michel Fauth wrote:

Hi Robin and all wxPython lovers,

The wxPython 2.5 release will be a milestone in the
wxPython series, I mainly think about the introduction of
the "wx package". Some comments and proposals.

i) wxPython relies on Python and wxWindows. wxPython users are
mainly Python users and not wxWindows testers. So the priority
should be set on Python. The actual Python version is 2.3
and it will stay for a long time. KA proposed to drop the
wxPython 2.1 branch. I will go further and I propose to
concentrate wxPython 2.5 solely on Python 2.3. The Python 2.3
changes are quite impressive and have a lot of consequences on
wxPython (depracated apply() function, deprecation warnings on
wrong types, new style classes, encoding, ...). From this mail
list, it seems most users have swithched to Python 2.3. The big
change in Python 2.3 offers the opportunity to make a big change
in wxPython.

ii) Every new wxPython release contains (at least) four things:
bug fixes, new widgets/controls (AnlogClockWindow), new features
(DrawXXXList), updated packages (stc). I think this is too
much at the same time. If you work on a project/application,
and you download a new version, you hope to see corrected bugs
and improved packages. You are not primarly interested in new
stuff.

iii) The point ii) is specially true, for people who develop
3rd-party packages for wxPython.

iv) The first release of wxPython 2.5 should be stamped as alpha
or beta, not 2.5.0 ; (wx.VERSION_STRING is a ...string).
(Downloading trial versions from CVS is too complicate for a lot
of users (including me)). Beside this, there are too many users
that understand 2.5.0 as the "first stable 2.5 version". I think,
the wxPython community (beta testers, not developers) will appreciate
a freezing around a 2.5.0alpha.

v) Any 2.5 documentation should be available on the user's
hard disk.

On my win platform, living with several wxPython versions is
not a problem. Which one to use it's just a question of
directories renaming. I will be very happy to test my apps with
the new wxPython 2.5.alpha and report about bugs.

Jean-Michel Fauth, Switzerland.

--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417

5

Seconded. We're in the same situation. I can convince folks to
update wxWindows versions more easily than I can convince them to
update Python itself.

···

On Thu, Sep 11, 2003 at 06:45:24PM -0700, Uwe C. Schroeder wrote:

it's maybe not a good idea to drop support for something that is
still actively used by a lot of people. A lot of "commercial" users
freeze versions, and that is a good thing. If you

--
Tim Lesher <tim@lesher.ws>
http://www.lesher.ws