[IronPython] Problem with Creating Executable using SharpDevelop

[Dave Fugate]

We've kept assembly version numbers the same for 2.0.x (and change the assembly file version for each patch release) so that hosted IronPython applications do not need to be rebuilt for each release.  This approach is great as it ensures binary compatibility for compiled applications built on top of IronPython but it also has one major disadvantage:  we have to be incredibly conservative in terms of bug fixing for patch releases.  This means zero changes to any method signature whether it's in the DLR or IronPython.  Also, we outright reject a number of bug fixes for patch releases based on their complexity alone which might cause instability in other areas.

Our current 2.6.x planning entails not only fixing a lot of "hard" bugs where the fixes themselves might cause new instability, but also far more bugs than any prior IronPython release series.  As such, we need the flexibility to change method signatures (without injecting public API incompatibilities in areas like hosting of course) between patch releases.  The safest way to do this for those building compiled applications with IronPython is to rev assembly version numbers for each release of 2.6.

Finally, please recall that earlier I said we "strongly suspect" we'll be using different assembly version numbers for 2.6.  This isn't set in stone yet:)  If you feel strongly on this one way or another, please let us know as this will influence the final decision.

Thanks,

Dave

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Tuesday, July 14, 2009 5:56 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop


On Mon, Jul 13, 2009 at 7:26 PM, Dave Fugate <dfugate at microsoft.com<mailto:dfugate at microsoft.com>> wrote:
On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc...

Can't you update AssemblyFileVersion and leave AssemblyVersion or is there a problem with that too?


-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Michael Foord
Sent: Monday, July 13, 2009 4:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop
Jeff Hardy wrote:
> On Fri, Jul 10, 2009 at 12:50 PM, Michael
> Foord<fuzzyman at voidspace.org.uk<mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>> Are there issues around assembly versions and the GAC? I'm thinking
>> particularly of where newer versions of IronPython are released as drop-in
>> replacements so the version numbers are not updated. If a previous version
>> is in the GAC isn't there a likelihood that an application that ships with a
>> newer version will still load the GAC'd older version... ?
>>
>> My *impression* was that adding stuff to the GAC was a recipe for DLL hell
>> and therefore it was better left to individual users rather than being
>> automatic on installation. This opinion may be ill-informed however...
>>
>
> You just have to be *really* careful with you assembly versions, and
> what kinds of changes cause a rev of version numbers. However, I don't
> think it should be the default, but it would be nice to have the
> option during installation. I think gacutil is only included in the
> SDK anyway.
>
>

Right. I think the issue of version numbering is tricky, which is why
I'm nervous about IronPython being GAC'd.

As an example, the IronPython 2.0.1 and 2.0 assemblies have the same
version numbers - and I understand why and don't disagree with this
decision - but the net result is that Resolver One required 2.0.1 and
would probably fail if the user has 2.0 in the GAC.

I certainly wouldn't object to it being an installer option, but it
would still make me nervous... :-)

Having minor IronPython versions have new assembly versions would
probably help - but with the disadvantage that they are no longer
drop-in replacements.


Michael

> - Jeff
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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