• ReleaseSeries

What is a wxPython Release Series?

The wxWidgets project has adopted the release model used by the Linux Kernel project where there are alternating sets of releases where one set are considered "stable" and the next set are considered "unstable." For wxWidgets "stable" and "unstable" do not refer to bugginess, but to the stability of the API and backwards compatibility.

• Stable: For the duration of the series existing APIs are not modified, although new non-virtual class methods and such can be added. Binary compatibility of the C++ libs is maintained by not allowing any changes that modify the in-memory size or layout of the classes and structs. This can and often does impose limitations on what kinds of enhancements or bug fixes can be performed in a stable release series.

• Unstable: The main purpose of the unstable series of releases is to add new functionality or to correct problems that could not be corrected in a stable series because of binary compatibility issues, all in an effort to create the next stable series. So for the duration of the unstable series existing APIs are allowed to be modified or removed as needed, although most of the time C++ source-level compatibility is maintained via deprecated overloaded functions or macros, etc. For wxPython this often means that there will be source-level incompatibilities because there is no overloading or macros, and in order to support the new version of the API sometimes the old version has to be removed.

Because of the binary compatibility issues, the latest unstable version of wxWidgets/wxPython can often be less buggy than the latest version of the last stable release series. However there is the tradeoff that the APIs may be changing or evolving between versions in the unstable series.

How do the version numbers work?

For releases wxPython uses a 4 component version number. While this looks a lot like how version numbers are used in other Open Source projects, there are a few subtle differneces. So for some release A.B.C.D you can deduce the following:

1. Release Series: The first two components of the version number (A.B) represent the release series, and if the B component is an even number then it is a stable series, if it is an odd number then it is an unstable release series. For example, 2.4, 2.6, and 2.8 are stable and the API is more or less frozen within each series, and 2.3, 2.5, and 2.7 are unstable and the API and functionality is allowed to change or evolve as needed.

Because of this there can be quite large changes between one stable series to the next (say 2.4 to 2.6) and this often throws people off because in other projects changes of that magnitute would have caused the first component of the version number to change. Instead you should think of the combination of A.B as being the major number of the version.

2. Release Number: The third component of the version number (C) represents one of the releases in a release series. For example, 2.5.0, 2.5.1, 2.5.2, 2.5.3... are all releases in the 2.5 release series. (And since in this case it is an unstable series then the API and functionality of 2.5.3 has evolved to be differnet in places than it was in 2.5.0.) The C++ wxWidgets releases stop here and only A.B.C releases are made.

3. Subrelease number, or wxPython release: The fourth component of the version number (D) is used to represent a subrelease, or incremental releases betweeen the official wxWidgets releases. wxPython uses this component to be able to release versions that have had bug fixes or new features implemented, but that have not yet found their way into an official wxWidgets A.B.C release. In addition wxPython release cantidate builds will usually each have a different D number in order for the testers to distinguish between them. This is why there was a 2.5.2.7 and 2.5.2.8, but no officially available verisons 1 to 6, they were all test builds.

Comments?