Robin could you comment on your plans for versions of wxPython after the 2.4
release. In wxWindows terms, an odd-number release 2.3.x, 2.5.x is
considered "unstable" and the API can change. wxWindows 2.4 is thus a very
important milestone for wxWindows as it means programs written to the 2.4
API don't have to worry about API changes to the 2.4 branch, future releases
such as 2.4.1 will just be bug fixes.
However, wxPython in the past has not followed that same release strategy.
Are you planning to start doing two distributions, one based on 2.4 with no
new features or API changes, only bug fixes and another branch for 2.5.x?
Robin could you comment on your plans for versions of wxPython after the 2.4
release. In wxWindows terms, an odd-number release 2.3.x, 2.5.x is
considered "unstable" and the API can change. wxWindows 2.4 is thus a very
important milestone for wxWindows as it means programs written to the 2.4
API don't have to worry about API changes to the 2.4 branch, future releases
such as 2.4.1 will just be bug fixes.
Correct.
However, wxPython in the past has not followed that same release strategy.
Are you planning to start doing two distributions, one based on 2.4 with no
new features or API changes, only bug fixes and another branch for 2.5.x?
Short answer: I havn't fully decided yet.
Long answer: My intent is to stay focused on the stable branch for some number of months and then as it settles to work on other things, like the reference docs, etc. That doesn't mean that there won't be new features added, some classes that are not wrapped yet may be added, or new library contribs or whatever, but the core C++ library will have a stable API and so the wrappers for those APIs will be stable too. I expect that I'll do some work on 2.5 from time to time, but in the short term I can only really focus effectivly on one branch at a time so there may not be any wxPython 2.5.x releases until it is getting closer to 2.6.
BTW, I wanted to do this with 2.2 also but wasn't able to for very long because of some critical bug fixes that only showed up on the development branch (2.3) because they required API changes, so it's possible that this may happen this time too. I think that wxWindows itself is in much better shape now too than it was at 2.2 so I think that my active work on 2.4.x should be able to last much longer this time.
One kink in this plan is my work for the OSAF. I think it makes sense for them to stay on the 2.4.x releases for the API stability, but some of the items on my TODO list will require API changes. They are keeping their own copy of wxWindows in their CVS so what I may end up doing is work on the wx 2.5 branch and then porting specific features to the 2.4-OSAF CVS, which would mean 3 CVS trees that I need to work on... (Can anybody say "my life is complicated"? Very good, I knew you could. ) On the other hand, the system architect at OSAF is a strong believer in latest and greatest, so maybe they will be using 2.5.x directly...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
2.4-OSAF CVS, which would mean 3 CVS trees that I need to work on... (Can anybody say "my life is complicated"? Very good, I knew you could. )
Oh yeah, multiply that by three platforms (or five if you want to count win9x vs. NT/2k/Xp and wxGTK vs. wxGTK2.) and multiply the windows and gtk2's by two for the ansi/unicode builds, and finally multiply the whole lot by 3 for the versions of Python. Please excuse me while I set my hair on fire and run screaming from the room...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
> 2.4-OSAF CVS, which would mean 3 CVS trees that I need to work on...
> (Can anybody say "my life is complicated"? Very good, I knew
you could.
> )
Oh yeah, multiply that by three platforms (or five if you want to count
win9x vs. NT/2k/Xp and wxGTK vs. wxGTK2.) and multiply the windows and
gtk2's by two for the ansi/unicode builds, and finally multiply the
whole lot by 3 for the versions of Python. Please excuse me while I
set my hair on fire and run screaming from the room...
What the OSAF decides to do re versions of Python and wxPython should be
brought up on the osaf dev mailing list soon. If the OSAF decides to deviate
from the standard Python builds or wxPython builds they will effectively cut
off their development from everyone else that might otherwise contribute to
the Chandler project. It is one thing to create additional packages and libs
that can be added on to a standard distribution, but that is not what you
are describing.
I'm already concerned by the fact that the "python in a tie" folks are
putting their focus on Python 2.2.x but that Mac OS X will not really have a
standard Python with 2.2.x but rather require 2.3.x
Without significant commercial backing for your work it doesn't make much
sense to try and keep a large active matrix of various platforms and
versions and even then you would need a QA team not just you. Python 2.1.x
and earlier support could be frozen at wxPython 2.4 or whatever your next
build is and from then on not worry about older Python versions.
If the API changes between wxWindows (and thus wxPython) versions is better
documented so that it is clearer where older code will break or required a
rework with checks for specific version features then simply following a 2.5
track for wxPython doesn't particularly bother me, but I know I won't
maintain two different versions on my box or bother with any testing of
different versions even if I only have to worry about binary installs. So, I
would rather you pick one or the other and go with it. There are too many
other problems to deal with. In order to maximize the usefulness of this
list and all our volunteer contributions it makes much more sense for
everyone to be using the latest stable version whenever possible.
Since one of the biggest hurdles for wxPython is to improve the
documentation, including noting behaviour differences between platforms it
is even more critical to reduce the matrix size we have to worry about.
2.4-OSAF CVS, which would mean 3 CVS trees that I need to work on...
(Can anybody say "my life is complicated"? Very good, I knew
you could.
)
Oh yeah, multiply that by three platforms (or five if you want to count
win9x vs. NT/2k/Xp and wxGTK vs. wxGTK2.) and multiply the windows and
gtk2's by two for the ansi/unicode builds, and finally multiply the
whole lot by 3 for the versions of Python. Please excuse me while I
set my hair on fire and run screaming from the room...
What the OSAF decides to do re versions of Python and wxPython should be
brought up on the osaf dev mailing list soon. If the OSAF decides to deviate
from the standard Python builds or wxPython builds they will effectively cut
off their development from everyone else that might otherwise contribute to
the Chandler project. It is one thing to create additional packages and libs
that can be added on to a standard distribution, but that is not what you
are describing.
Not really, it would just be 2.4.x with a few new features from 2.5 ported over. This is all still conjecture on my part anyway. After 2.4 is done I plan on taking a breath and discussing with the OSAF guys what approach would be best.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I agree with this 100%. Robin, make your life a little easier. We want you to stay sane.
Bob
···
At 02:32 PM 1/3/2003 -0800, you wrote:
> Robin Dunn wrote:
> > 2.4-OSAF CVS, which would mean 3 CVS trees that I need to work on...
> > (Can anybody say "my life is complicated"? Very good, I knew
> you could.
> > )
>
> Oh yeah, multiply that by three platforms (or five if you want to count
> win9x vs. NT/2k/Xp and wxGTK vs. wxGTK2.) and multiply the windows and
> gtk2's by two for the ansi/unicode builds, and finally multiply the
> whole lot by 3 for the versions of Python. Please excuse me while I
> set my hair on fire and run screaming from the room...
Without significant commercial backing for your work it doesn't make much
sense to try and keep a large active matrix of various platforms and
versions and even then you would need a QA team not just you. Python 2.1.x
and earlier support could be frozen at wxPython 2.4 or whatever your next
build is and from then on not worry about older Python versions.