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

[Jeff Hardy]

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