On Thu, Apr 10, 2014 at 7:31 AM, Vernon D. Cole <vernondc...@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 out. 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.jasin...@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 _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
