On Mon, Jul 20, 2009 at 3:45 PM, Charlie Groves<charlie.groves@...> wrote:
> On Mon, Jul 20, 2009 at 12:00 PM, Jim Baker<jbaker@...> wrote:
> I think we're breaking with CPython conventions here in that we want
> to have releases with features in them using the minor version number.
> I'd like to have a way to distinguish bugfix releases that people can
> upgrade to with less danger of things breaking, and tacking another
> number on the end is a decent way of doing that.
Having our numbering scheme locked to CPython's Major and Minor
version numbers is nice, because it makes it easy for users to
understand which version of CPython we are trying to be. It does have
its disadvantages, though. We are definitely breaking with CPython
conventions by having features show up in Micro releases. In fact,
they are very rigorous in this area -- they insist on the ability to
have safe *downgrades* -- the principle being that it should be safe
to develop on 2.5.1 and then move your code unchanged down to 2.5.0
with some confidence. I would like to get to that level of maturity
someday... but we are definitely not there yet. I think (for now)
that adding a Micro Micro number (Nano?) would only add more confusion
right now -- it feels like 126.96.36.199 would be saying: We are changing
even less than CPython does on Micro releases, which wouldn't be true
at all. We should definitely put up a doc that explains are
versioning scheme, and how it is similar + different than CPython's.
If we do end up putting out so many Micro releases that it feels out
of hand (I don't think I'd like to get to 2.5.10), maybe we should
consider Nano numbers -- but I'm not ready to do that yet (again I
think it would add to the confusion, not subtract).
>> In triaging 1406 and 1407, they're arguably important enough to suggest an
>> early release. However, they do not cause a crash (a trappable exception is
>> thrown) and simple workarounds exist. A one month cycle to RC allows us to
>> work some other outstanding bugs, do a few more performance improvements,
>> and implement any ready features.
>> In terms of features, 2.5.1 originally was to include not only clamp, but
>> bz2, CJK codecs, ctypes, JSR223, sqlite3, and unicodedata (full support), as
>> well as the Python bytecode compiler. At best, a few of these are doable in
>> a month, but not all of them. (If I were to guess, they would be ctypes,
>> JSR223, and sqlite3, although sqlite3 has no owner I'm aware of). It would
>> be best then if we just released early and waited until 2.5.2 (or perhaps
>> even latter) for these features.
> That's a huge set of features, so making a release in a month the same
> level of version bumpage as the release that contains all of that is
> quite misleading.
There may be an argument that some of these features are just to big
for 2.5.x, and should perhaps be put off to 2.6. I doubt all of them
will even make it for 2.5.2. By the time 2.5.2 comes out, I hope we
have a reasonable start on 2.6 and can talk about deferring some of
these to 2.6.
An argument could be made that some of the features listed above could
be regarded as bug fixes (though I know this is stretching it) as
Features that exist in CPython 2.5 but not Jython 2.5:
bz2, CJK codecs, ctypes, sqlite3, unicodedata
Features that existed in previous Jython versions that are not in this one:
JSR 223 + an answer to jythonc
Features that are only half implemented in Jython 2.5:
the Python bytecode compiler