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-boun...@lists.ironpython.com [mailto:users-boun...@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 <dfug...@microsoft.com<mailto:dfug...@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-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@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<fuzzy...@voidspace.org.uk<mailto:fuzzy...@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@lists.ironpython.com<mailto:Users@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@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
