Hi all,
I was just reviewing the changes I made for Phoenix version numbers. See
for starters.
The biggest difference from Classic is dropping the 4th component of the
version number, with the intent of using the setupttools/PEP-0386 concept for post-release build numbers for additional Phoenix builds using the same wxWidgets version. However PEP-0440 explicitly states:
So using the post release numbers that way is probably a bad idea. IIRC, the reason I wanted to drop the 4th component of the version is because bdist_msi doesn’t recognize a 4 component version as a valid version number, but now that wheels are the most common and the most desired distribution format, having the ability to make MSIs is a lot less important.
Also, since the Phoenix source includes a wxWidgets snapshot (via a git submodule or an actual snapshot in the tarballs) then I think using the version number to tie us to specific wxWidgets releases is a lot less important as well. So I think we have some options for alternative approaches we can take here, and I’m curious what you guys think.
: Go back to four version number components like Classic, where the first three match wxWidgets and the forth is a wxPython version number. I have never liked this but since wxPython was often tied to specific release versions of wxWidgets and since to begin with people were expected to get and build wxWidgets separately, and without a good way to link to those versions other than documenting it, using the duality of the version number seemed the best and maybe only way to do it reliably.
: Slightly decouple from the wxWidgets version number. By this I mean that we keep matching
the first two components of the wx version number, and the 3rd component is the Phoenix version. I like this for a couple reasons. : Totally disconnect from the wxWidgets version numbers, and have all 3 components of the version be a Phoenix version number. I don’t think I like this one if we use a normal version number like MAJOR.MINOR.RELEASE, but maybe using
a partially date-based version number would make sense, like YYYY.MINOR.RELEASE (for example, 2016.1.0, 2016.1.1, etc.).
I think I like option 2 the best. What do you guys think? Anybody have
other options to suggest?
···
https://github.com/wxWidgets/Phoenix/blob/master/buildtools/version.py
The use of post-releases to publish maintenance releases containing actual bug fixes is strongly discouraged. In general, it is better to use a longer release number and
increment the final component for each maintenance release.
Option 1
Option 2
-
It keeps the version at three components which is what most of the software in the world uses.
-
Very few of the Classic N.N.N.X releases, where X>0, actually used the real wxWidgets N.N.N release anyway, they were usually N.N.N plus some additional commits. So the implied use of the N.N.N release was usually not true anyway.
-
When discussing wxWidgets releases we usually refer to the collections of releases with matching MAJOR.MINOR numbers as a “Release Series”, so with this option you can think of the version number as {wxWidgets ReleaseSeries}.{Phoenix Release} and the nitty-gritty details about exactly which micro version (with possible extra commits) of wxWidgets which is being used is managed implicitly by virtue of the the snapshot of the wxWidgets code being included in the Phoenix source tree.
Option 3
–
Robin Dunn
Software Craftsman