While thinking about the upcoming 2.3.3 release I have come up with some
more things that I would like to get feedback from the community on.
1. Package/Installer naming: I'm going to standardize a bit and change the
names of the installers and packages (as in RPMs and .dmg's, *not* Python
packages) and use the name of the wx port in the name. For example:
wxPythonMSW, wxPythonGTK, etc. Hopefully someday there will be a
wxPythonX11... I'm not sure though what to do about the Mac OSX version.
There are in effect several wx ports that run on the Mac, Classic, Carbon,
and an OSX-only version built using the Apple Developer Tools. Currently
wxPython only works with the latter one. So should it be wxPythonMac,
wxPythonOSX, wxPythonMacOSX, wxPythonMacho, or ???
2. Python versions: I plan on doing binary builds for both Python 2.1 and
2.2, (except on the Mac where it will only be 2.2.) Is this enough? If
not, why not?
3. Compile options: I'm thinking about dropping the -hybrid builds (and
also the -dbg RPM I just announced) and instead do a single build that is
something in between the FINAL and HYBRID that I've done in the past.
Specifically it will be like the FINAL in that compiler optimizations will
be turned on and debugging info won't be generated, but __WXDEBUG__ will be
turned on so that the various runtime checks will always be there. As it is
now it takes me a complete a day to do all the builds and to do test
installs, much longer if I have to make changes to installers, etc. I'd
like to chop that in half if possible.
That's all for now.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
3. Compile options: I'm thinking about dropping the -hybrid builds (and
also the -dbg RPM I just announced) and instead do a single build that is
something in between the FINAL and HYBRID that I've done in the past.
Specifically it will be like the FINAL in that compiler optimizations will
be turned on and debugging info won't be generated, but
__WXDEBUG__ will be
turned on so that the various runtime checks will always be
there. As it is
now it takes me a complete a day to do all the builds and to do test
installs, much longer if I have to make changes to installers, etc. I'd
like to chop that in half if possible.
Does this mean that ASSERTS will be thrown at runtime, bringing up the
dialogs as in the Hybrid builds? How about the memory "leak" messages upon
exit? I don't think either of those should be in any 2.3.3 final.
1. Package/Installer naming: I'm going to standardize a bit and
change the
names of the installers and packages (as in RPMs and .dmg's, *not* Python
packages) and use the name of the wx port in the name. For example:
wxPythonMSW, wxPythonGTK, etc. Hopefully someday there will be a
wxPythonX11... I'm not sure though what to do about the Mac OSX version.
There are in effect several wx ports that run on the Mac, Classic, Carbon,
and an OSX-only version built using the Apple Developer Tools. Currently
wxPython only works with the latter one. So should it be wxPythonMac,
wxPythonOSX, wxPythonMacOSX, wxPythonMacho, or ???
wxPythonMacOSX +1
After thinking about the other names a little more I suggest wxPythonWindows
over wxPythonMSW for the simple reason that only people already deeply
familiar with wxWindows will know what the heck MSW stands for. wxPythonGTK
is obvious for Linux folks, so that's okay.
2. Python versions: I plan on doing binary builds for both Python 2.1 and
2.2, (except on the Mac where it will only be 2.2.) Is this enough? If
not, why not?
A Python 2.3 alpha/beta release (when a 2.3 build is available) would be
nice.
> 3. Compile options: I'm thinking about dropping the -hybrid builds (and
> also the -dbg RPM I just announced) and instead do a single build that
is
> something in between the FINAL and HYBRID that I've done in the past.
> Specifically it will be like the FINAL in that compiler optimizations
will
> be turned on and debugging info won't be generated, but
> __WXDEBUG__ will be
> turned on so that the various runtime checks will always be
> there. As it is
> now it takes me a complete a day to do all the builds and to do test
> installs, much longer if I have to make changes to installers, etc. I'd
> like to chop that in half if possible.
Does this mean that ASSERTS will be thrown at runtime, bringing up the
dialogs as in the Hybrid builds?
Yes.
How about the memory "leak" messages upon
exit?
No. Although I like having them (they let you know you are doing something
wrong) I don't think they add enough value in the general case.
I don't think either of those should be in any 2.3.3 final.
You would rather have it silently crash with no explaination?
What is the timeframe for a 2.3.3 final release?
Still unknown. I think all the core developers would like to do it as soon
as possible, (after a few little things are taken care of) it's just a
matter of finding the time.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
My reason for not wanting the ASSERTS and memory leak info is that in my experience with wxPython for the last year both of those have only provided potentially useful information for developers of applications, never end users. The memory leak info is generally of questionable value for any items that are not freed until program exit anyway. The asserts provide a warning, but that doesn't mean that the call was illegal. I don't ever remember either asserts or leaks helping with issues that would cause a crash. Again, this is developer stuff, not end-user stuff.
So, I guess I'm arguing for two separate releases still. Something that everyone uses and something that only developers will probably use. That doesn't help with your compile issue, but maybe you only put out the "for everyone" releases once everything is finalized.