As you state yourself there have been changes to the public API - could we provide types that match the public API in Castle.IO matching what openwrap expects?
Would you like to have a look yourself at the code? At the moment, you can work off of haf/Castle.Transactions, but the IO will be moved to its own top-level project in haf/Castle.IO shortly. Other than that, I think it sounds good. Cheers, Henrik On Oct 25, 9:55 am, Sebastien Lambla <[email protected]> wrote: > Hi guys, > > So I've now researched things enough and prototyped where we are with OFS in > regards to openwrap and backward/forward compat. > > As I feared, we're a bit stuck: if and when we upgrade OFS, old versions of > OpenWrap may load up the wrong version at runtime and break, so I need to > ensure binary compat for the foreseeable future. > > The transition to Castle.IO is going to be a bit complicated and is probably > gonna involve wrapping things from one namespace to the other during the > transition. With OW 2.0 we won't have the problem as dependency resolution > for bootstrap package is is more accurate, and auto-upgrades will not happen > by accident. > > How we're gonna go from A to B is gonna be a challenge but ah well, it's > probably worth it. OFS will be migrated to be a layer on top of the native > Castle.IO, and provide platform-levelling (so we can "fake" symlinks, > hardlinks or some transactions on platforms / file systems that don't support > them, or at least try very hard). > > Anway, that's the current plans as they exist. -- 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.
