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 <jdha...@gmail.com> wrote: > On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondc...@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@python.org > https://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
