On 6 Feb 2007 08:46:29 -0800, Ben Sizer <[EMAIL PROTECTED]> wrote: > On Feb 6, 3:35 pm, [EMAIL PROTECTED] (Aahz) wrote: > > Ben Sizer <[EMAIL PROTECTED]> wrote: > > > > >It would be great if someone could invest some time in trying to fix > > >this problem. I don't think I know of any other languages that require > > >recompilation of libraries for every minor version increase. > > > > How do you define "minor version increase"? If you look at the > > progression from 2.0 through 2.5, it's pretty clear that each version > > doesn't particularly fit "minor version increase" even though each one > > only increments by 0.1. > > I can't say I agree with that. In terms of naming, it's a minor > release because the 'major' release number has stayed at 2. In terms > of time, it's a minor release because it's only happening about once > every 18 months or so - a short period in computer language terms. In > terms of semantics, I'd argue they are minor releases because > generally the changes are just minor additions rather than large > revisions; I don't see much in the way of significant language > alterations for 2.5 apart from arguably 'unified try/except/finally', > nor in 2.4. I don't count addition of new types or modules as 'major'. > The language itself is fairly stable; it's just the way that it links > to extensions which is pretty fragile. > > -- > Ben Sizer >
You're claiming that it's a minor increase because you didn't see anything that "justifies" a major release. Well, the ABI changed, so there you go. It doesn't really matter what you call it - the Python releases are numbered according to their own rules, and if you disagree you can call 2.5 a major release all you want. Or you can call it a minor release and accept that the ABI changes between minor releases. But making up your own release rules and arguing from those is pretty much a non-starter. -- http://mail.python.org/mailman/listinfo/python-list