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

[Olof Bjarnason]

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
convention.

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
> https://mail.python.org/mailman/listinfo/ironpython-users