[IronPython] IronPython 2.6 version numbers

[Dino Viehland]

> Hi IronPython team,
> I don't know if this is even an issue, but I'd like to make a request
> for the IronPython 2.6.x releases - please do not change the
> AssemblyVersion from 2.6.0, or make any ABI breaking changes. I'll
> admit, this is mostly because of my own laziness; I don't want to have
> to respin NWSGI for every minor IronPython revision just to update the
> assembly references, but I also don't want the headache of tracking
> which NWSGI version are compatible with which IronPython 2.6 minor
> versions.
> 
> The only reason I bring this up is because Dave had mentioned a while
> ago that they wanted to use different versions for the minor releases
> (see http://lists.ironpython.com/pipermail/users-ironpython.com/2009-
> July/010766.html
> for full email):
> 
> "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."
> 
> Changing the assembly version (and method signatures) will be a huge
> pain to extension/hosting authors. To me, the hard fixes should go
> into the 2.7/3.0 development branch, not into the 2.6 release branch.
> At the time Dave said it was not set in stone - I hope it's still not
> too late.

We're going to look into using publisher policy if we feel the need to
rev the assembly version number.  That should cause apps to automatically
upgrade but also someone could look at locking back to a specific 
version if necessary.  

If that doesn't work as well as we expect then I think you're right that
we can't really require re-building for minor upgrades.