From: Frank W. <fwi...@gm...> - 2009-07-20 15:22:15
|
A couple of recent bug reports are severe enough that I'd like to set a harder date for 2.5.1. Those bugs are http://bugs.jython.org/issue1406 and http://bugs.jython.org/issue1407 which are problems with co-routines that work in CPython but fail to verify or throw ClassCastException for Jython. Tobias has already fixed the first, and is looking at the second. I am thinking of targeting August 20 for 2.5.1rc1, which would mean we should have a feature freeze around August 13 so we can have a little time to harden for releasing. Any objections? -Frank |
From: Charlie G. <cha...@gm...> - 2009-07-20 18:24:58
|
On Monday, July 20, 2009, Frank Wierzbicki <fwi...@gm...> wrote: > A couple of recent bug reports are severe enough that I'd like to set > a harder date for 2.5.1. Those bugs are > http://bugs.jython.org/issue1406 and http://bugs.jython.org/issue1407 > which are problems with co-routines that work in CPython but fail to > verify or throw ClassCastException for Jython. Tobias has already > fixed the first, and is looking at the second. > > I am thinking of targeting August 20 for 2.5.1rc1, which would mean we > should have a feature freeze around August 13 so we can have a little > time to harden for releasing. > > Any objections? Haven't we promised to include clamp and the like in 2.5.1? I've been making pretty good progress on it since I started working on it again, but in particular I don't see the machinations necessary to get all the standard lib proxies compiling being finished within a month. Maybe this should be a purely bugfix release, 2.5.0.1, instead of one including new features? Charlie |
From: Jim B. <jb...@zy...> - 2009-07-20 19:01:00
|
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.) 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. - Jim On Mon, Jul 20, 2009 at 12:24 PM, Charlie Groves <cha...@gm...>wrote: > On Monday, July 20, 2009, Frank Wierzbicki <fwi...@gm...> wrote: > > A couple of recent bug reports are severe enough that I'd like to set > > a harder date for 2.5.1. Those bugs are > > http://bugs.jython.org/issue1406 and http://bugs.jython.org/issue1407 > > which are problems with co-routines that work in CPython but fail to > > verify or throw ClassCastException for Jython. Tobias has already > > fixed the first, and is looking at the second. > > > > I am thinking of targeting August 20 for 2.5.1rc1, which would mean we > > should have a feature freeze around August 13 so we can have a little > > time to harden for releasing. > > > > Any objections? > > Haven't we promised to include clamp and the like in 2.5.1? I've been > making pretty good progress on it since I started working on it again, > but in particular I don't see the machinations necessary to get all > the standard lib proxies compiling being finished within a month. > > Maybe this should be a purely bugfix release, 2.5.0.1, instead of one > including new features? > Charlie > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- Jim Baker jb...@zy... |
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 |
From: Frank W. <fwi...@gm...> - 2009-07-21 14:05:42
|
On Mon, Jul 20, 2009 at 3:45 PM, Charlie Groves<cha...@gm...> wrote: > On Mon, Jul 20, 2009 at 12:00 PM, Jim Baker<jb...@zy...> 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 2.5.0.1 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 follows: 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 -Frank |
From: Kay S. <ka...@fi...> - 2009-07-23 05:07:17
|
Frank Wierzbicki schrieb: >> 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. > I'd break with the current versioning scheme entirely and push Jython forward aggressively incorporating Python 3.X features like function annotations at this stage - i.e. everything that leads to conservative extensions in the 2.X series. Holding relevant features backwards just because of confusing version numbers is harmful. Let the compliancy somehow show up but let it not dominate projects progress. I'd suggest something along the lines of Jython 1.0-C2.5 where the hyphenated postfix -C2.5 indicates CPython compliancy and the major-minor-subminor-... being prefixed can be varied independently. The learning curve isn't incredibly steep for newcomers. Given the slow adoption of Python 3.X it is clear that Jython can live with this for quite a long time. It might even happen that more people adopt Jython because they want to have the new features without their code getting broken. Regards, Kay |
From: Frank W. <fwi...@gm...> - 2009-07-20 19:00:47
|
On Mon, Jul 20, 2009 at 2:24 PM, Charlie Groves<cha...@gm...> wrote: > Haven't we promised to include clamp and the like in 2.5.1? I've listed clamp as a priority for 2.5.1 - but I think I'll just have to explain to everyone that there where a couple of must-fix bugs that prompted an early 2.5.1, and that clamp support will have to wait for 2.5.2 (unless clamp itself can release between 2.5.1 and 2.5.2). I've also always talked about clamp as a separate project -- and I think it might be a good idea to keep it that way for now. A separate clamp project can then evolve on it's own without being locked into Jython's release cycle. -Frank |
From: Charlie G. <cha...@gm...> - 2009-07-20 19:48:19
|
On Mon, Jul 20, 2009 at 12:00 PM, Frank Wierzbicki<fwi...@gm...> wrote: > On Mon, Jul 20, 2009 at 2:24 PM, Charlie Groves<cha...@gm...> wrote: >> Haven't we promised to include clamp and the like in 2.5.1? > I've listed clamp as a priority for 2.5.1 - but I think I'll just have > to explain to everyone that there where a couple of must-fix bugs that > prompted an early 2.5.1, and that clamp support will have to wait for > 2.5.2 (unless clamp itself can release between 2.5.1 and 2.5.2). I've > also always talked about clamp as a separate project -- and I think it > might be a good idea to keep it that way for now. A separate clamp > project can then evolve on it's own without being locked into Jython's > release cycle. I created it as a separate project for that reason, but the initial release is going to require a Jython release to enable various proxy and Java integration features it needs. Charlie |