[Ironpython-users] IronPython 3 Version Number (Was: Item 34263 in 2.7.5?)

Jeff Hardy jdhardy at gmail.com
Thu Apr 10 10:18:43 CEST 2014

On Thu, Apr 10, 2014 at 7:31 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> -1 on version number 3.0.
> Just last week I was in a complete panic when I discovered that the version
> of Python embedded in moneydance was "Jython 2.0".  After some frantic
> searching, I discovered that Jython 2.0 implements Python 2.5.  Their
> current beta is numbered 2.7b1 because of such confusion.
> I also seem to remember many emails and other explanations about "IronPython
> version 2.0 implements the Python 2.5 specification" so that the next
> version of IronPython was numbered to match the language spec.   That is a
> good tradition to keep.

I completely understand where you're coming from, and for IronPython
2.7 I think this was a good match. My concern is that this limits the
ability of IronPython to evolve in other ways not tied to CPython
versions. For example, consider issue 34263 that started this thread:
if IronPython 2.7 was instead 2.3, I would have no problem issuing a
2.4 with the Frames behaviour changed, but calling it 2.8 is right

In addition, 3.0 will include most (but perhaps not all!) of 3.4's
features, mainly because I'd like to see a release later this year
(around October) and things like nonlocal or importlib could slip
because they're hard and not terribly exciting. Calling a release like
that 3.4 is a problem because it's really not 3.4-compatible.

Once the Python 3 features are in place, I want to make it as
cross-platform as possible - iOS, Android, Windows 8, etc. That would
strongly imply a new version number since it will require a new DLR
version to be used (not very good to slip a DLR version change into a
3.4.z release). Hence I'd prefer to keep the ability to call it 3.1
(or whatever) instead.

Finally, PyPy does not synchronize version numbers with CPython, and
they seem to be doing just fine. That's why sys.implementation has the
ability to distinguish interpreter version (say 3.0) from
sys.version's language version (3.4).

Of course, my mind is willing to be changed if enough people disagree,
but until we can match CPython exactly I'd prefer to keep the version
numbers independent.

On Thu, Apr 10, 2014 at 1:20 AM, Pawel Jasinski
<pawel.jasinski at gmail.com> wrote:
> My typical use case is python.org docs. For ironpython 2.7, I select 2.7 for 3.0, hm ... 3.0, 3.4 or 3.5?

Hopefully, IronPython 3 docs. Keeping a fork of the docs will be a bit
more work, but the advantage is that we can describe any IP-specific
quirks that may exist and also have a home for real documentation,
like how to embed IronPython and a cleaned-up version of the CLR
interop doc. And readthedocs.org will take care of hosting.

- Jeff

More information about the Ironpython-users mailing list