Thoughts on Phoenix version numbers

Hi all,

I was just reviewing the changes I made for Phoenix version numbers. See 
https://github.com/wxWidgets/Phoenix/blob/master/buildtools/version.py 
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:

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.


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.

Option 1: 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.

Option 2: 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.

1. It keeps the version at three components which is what most of the 
software in the world uses.

2. 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.

3. 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: 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?

-- 
Robin Dunn
Software Craftsman
http://wxPython.org

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.