From: Charlie G. <cha...@gm...> - 2009-07-20 19:46:02
|
On Mon, Jul 20, 2009 at 12:00 PM, Jim Baker<jb...@zy...> wrote: > Given the definition of sys.version_info, and the normal Python conventions, > I think it would be better if we released a "2.5.1" than a "2.5.0.1". (I > suppose the serial component could be used, but I don't recall it being used > in the past.) 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. > 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. Charlie |