Hi, You have commit access to haf/Castle.IO and haf/Castle.Transactions
Castle.Transactions contains Castle.IO till the next release, which is probably an alpha of Castle.IO and a GA of Castle.Transactions and a beta of Castle.Transactions.IO. After this release, I plan on separating that code into its own repository ON MY OWN GITHUB which you have commit access to. I will then merge that into Castle.Transactions when Castle.Transactions or Castle.IO is released, and push to castleproject/Castle.Transactions. How about this? Cheers, Henrik -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sebastien Lambla Sent: den 26 oktober 2011 15:36 To: [email protected] Subject: RE: Castle.IO & OpenFileSystem >From where I stand right now (and until the Castle integration / commit access / integration issues are resolved), I may have to simply continue handling OFS with the existing APIs and backport your changes to the project under the OFS namespace / brand. I'll leave it for a couple more weeks, see where we are with all that then before making a decision. ________________________________________ From: [email protected] [[email protected]] on behalf of Henrik [[email protected]] Sent: 25 October 2011 14:27 To: Castle Project Development List Subject: Re: Castle.IO & OpenFileSystem 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. -- 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.
