Re: Thoughts on Phoenix version numbers

Scott Talbert <[email protected]>
Newsgroups gmane.comp.python.wxpython.devel
Message-ID <[email protected]>
On Mon, 9 May 2016, Robin Dunn wrote:

> 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 2 seems fine with me.  It seems it gets across the most information 
information - wxWidgets API version + a Phoenix release version based on 
that.

When building for distributions (Fedora, Debian), we don't use the bundled 
copy of wxWidgets anyway, so knowing the exact version of that is not 
important.

Scott
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.