We're actually following the example of the CLR and other managed libraries here not something from dynamic languages :). Minor non-breaking releases are in-place upgrades - for example you don't have mscorlib at version 2.0.50727.42, mscorlib at version 2.0.50727.3521 and a ton of versions in between - you just have mscorlib at the version it shipped at in 2005 which is 2.0.50727.42. But it's file version changes with every patch so you can determine exactly what version you have. And it's the same w/ all of the other framework DLLs as well. So for major versions I agree with you - managing policy files is a way of life, but for minor versions not reving the assembly version is also a way of life.
As for concerns of breaking changes... The 2.0 branch is locked down and only sees targeted changes that are explicitly back ported. This is different from the major releases and the betas where there was active development which can and does alter APIs. So we do maintain a high bar of compatibility between these point releases. It's also what we've done with all the 1.x.y point releases as well so there isn't some new precedent here. We could switch to updating the assembly version between minor versions but I'd like to have evidence that we are indeed breaking things first. We have been more liberal than the frameworks (allowing signature changes in modules because they shouldn't be called directly from C#) but we haven't been hearing about problems to date. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, February 13, 2009 3:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0.1 I guess one man's feature is another man's dll hell. We've had lots of problems going from IP 2.0 Beta to IP 2.0. Running an installer that wants to put the dll in GAC when there's already that version there seems to fail. I've got to guide people through digging into the GAC and checking the file version to find out they've got the wrong version. I thought it was just a beta to release thing, IP 2.0 was not compatible with the IP 2.0 Beta (not that I expect it to), but what if there are breaking changes and we need to install side-by-side? Managing policy files and being explicit about versions is a .NET way of life. I think maybe you guys have had your heads in the dynamic sand for too long :) ________________________________ From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, February 13, 2009 2:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0.1 It's an in-place upgrade so you don't need to re-build hosts that were built against the previous versions of IronPython - they'll just continue to work. If we changed the .NET assembly version then you'd either have to apply policy or rebuild. The assembly file version is updated and that's how you can distinguish the two builds. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, February 13, 2009 2:32 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0.1 Why is the assembly version the same as 2.0? ________________________________ From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dave Fugate Sent: Friday, February 13, 2009 2:19 PM To: Discussion of IronPython Cc: python-announce-l...@python.org Subject: [IronPython] Announcing IronPython 2.0.1 Hello Python Community, I'm pleased to announce the release of IronPython 2.0.1. IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running under the .NET platform. Our top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0. One of many notable areas we've improved upon is that float-integer comparisons are now 74% faster than they were in 2.0. A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf. A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements. In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release: * 20632: can't write a __len__ returning a uint * 20492: TupleExpression.IsExpandable is internal, should be public * 20605: Compiling with pyc and PySerial module * 20616: wrong TypeError message when invoking "str.join": implicit parameter 'self' not counted * 20623: InitializeModule needs to add refs to mscorlib/System We'd like to thank everyone in the community who contributed to these bugs: fwereade, Eloff, neraun, and kuno. You can download IronPython 2.0.1 at: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481 The IronPython Team ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto.
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
