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

[Vernon D. Cole]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20140411/4496acd1/attachment.html>