Daniel,
but there are breaking changes between versions.
You could use OpenWrap which strips strong name from the assembly, then
the assebly will get loaded regardless of the version it has.
On 9/09/2010 8:08 AM, Daniel Hölbling wrote:
Ok, this sounds totally crazy.
But what if we stop incrementing the assembly version number of
Castle.Core unless there are breaking changes to it?
Currently there are like 3 different versions of Castle.Core out in
the wild, and it's pretty tough to find 2 other OSS projects that
agree on one shared version.
Since the loader only checks the version number, only labeling the
build (with a 2.5.version file in it's root or whatever), but leaving
the assembly version at some fixed thing would mean: everyone can just
drop in a newer Castle.Core in the lib directory and wouldn't have the
need to recompile.
Whenever I did a custom compilation of other OSS frameworks against a
newer Castle.Core it was literally exchanging the old dll with the new
one and building the thing. I've never encountered breaking changes ever.
Especially with projects like nu that offer some metadata, and some
good communication on our part this would really solve a lot of problems.
What do you think?
The disadvantages are there of course, but we can still set the
FileVersion and also add the version to the description of the assembly.
greetings Daniel
--
You received this message because you are subscribed to the Google
Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
