@john: Yes, but nobody does that with castle since they need to expose stuff like ILogger and IInterceptor.
It's easy to internalize libraries that are only used internally. But once the user has to call the types in that library you are screwed and back to square one. (ayende is giving out 2 version of rhino mocks because of this. One merged one not) @kozmic: How many breaking changes? I haven't seen any problems upgrading so far. Greetings On 09.09.2010, at 03:21, John Simons <[email protected]> wrote: Hi Daniel, I thought you came up with a solution for this before: http://www.tigraine.at/2009/10/01/using-ilmerge-to-hide-your-dependencies/ Cheers John ------------------------------ *From:* Daniel Hölbling <[email protected]> *To:* [email protected] *Sent:* Thu, 9 September, 2010 8:08:10 AM *Subject:* Crazy Idea to end dependency hell? 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. -- 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.
