[Ironpython-users] IronPython 3 Version Number (Was: Item 34263 in 2.7.5?)
olof.bjarnason at gmail.com
Fri Apr 11 09:50:29 CEST 2014
To just add my relative outsider opinion (new user of IronPython, 5+
year user of CPython).
As long as a IronPython version does not adhere 100% to a CPython
version, it does not make sense to follow same version name
Better then to have a completely different "scale", e.g. 0.xyz. In
fact, as long as IronPython doesn't adhere to CPython <some version>,
does it even make sense to have a version beyond 1.0?
On the topic of Python compliance, how do you determine exactly how
compliant IronPython is? How does PyPy determine this?
On 10 April 2014 11:39, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
>> Jeff Hardy stated:..
>>> 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.
>> True, but calling it 3.3 would not be a problem, I think.
> But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And
> I'm not saying we won't get to nonlocal, it's just an example).
> IronPython 3 likely isn't going to line up with any CPython 3 release
> feature-wise at first.
>>> 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.
>> Well, speaking of cross-platform, most of my work in the near future will
>> probably be on Mono -- so different DLRs will be kind of a normal thing. I
>> don't have a problem with that being a factor in a point-level release -- it
>> is an implementation detail, not a language change.
> It's an issue if there are multiple languages depending on the same
> DLR version, which was one of the promises of the DLR. Now, I'm not
> sure anyone *uses* that ability, but I don't want to casually throw it
> away, either.
> I think there's an expectation that in an x.y.z scheme, z releases
> should not make major changes. If IronPython's x.y is fixed to
> CPython's, then our ability to make major changes is tied to CPython's
> ~18 month release schedule. At least for the next few releases I'd
> like the flexibility to increase version numbers in accordance with
> expected norms (i.e. as close to semver as we can manage), but if/when
> we catch up then maybe it makes sense to synchronize.
> - Jeff
> Ironpython-users mailing list
> Ironpython-users at python.org
More information about the Ironpython-users