[IronPython] Announcing IronPython 2.0.1

Sat Feb 14 00:56:16 CET 2009

Do you think that anyone providing a framework or library (code meant to
be consumed developers) should follow these guidelines (red and green
bits)?  Or should all products follow these guidelines?

Or does it depend where you are on the food chain?  It doesn't seem to
match with the guidance Microsoft provides in general to developers.

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

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-bounces at lists.ironpython.com
[mailto:users-bounces at 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-bounces at lists.ironpython.com
[mailto:users-bounces at 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-bounces at lists.ironpython.com
[mailto:users-bounces at 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-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at 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?ReleaseI
d=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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090213/e8f088ee/attachment.html>