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.
