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