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

[Olof Bjarnason]

OK, that sounds like a reasonable way to do it. Very nice that it is
automatically verifiable!

But it opens more questions from me, sorry. I find this interesting :)

So when an automatic test, that is determined to be a implementation
detail, fails - how does IronPython "skip" it? Is the actual test
suite specific for IronPython? I mean, is the unit tests in IronPython
a fork of CPythons test suite?

Anyone know how many per cent of the CPython test suite that IronPython pass?


On 11 April 2014 10:52, Vernon D. Cole <vernondcole at gmail.com> wrote:
> Compliance is determined by running the same test suite as CPython (the
> reference implementation).  The only tricky part is, should a test fail,
> determining whether it is testing a language feature (must fix) or an
> implementation detail (can skip).
>    For example, tests involving the Garbage Collector or GIL would be
> skipped, because IronPython does not use them.
>
>
> On Fri, Apr 11, 2014 at 1:50 AM, Olof Bjarnason <olof.bjarnason at gmail.com>
> wrote:
>>
>> 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
>
>