However, we can discuss whether it should be in a *git repository* on the top level, as long as it's marketed well. If it's more convenient to have it in a non-top level repository in terms of building (the reason for the whole discussion), I can place it in the Castle.Transactions repo without a problem!
From: [email protected] [mailto:[email protected]] On Behalf Of Henrik Feldt Sent: den 25 oktober 2011 17:39 To: [email protected] Subject: RE: New Castle.IO project? @hammett: But you are not backtracking from this thread. It's a new project, by majority vote. So castle is *the* vehicle. Cheers, Henrik From: [email protected] [mailto:[email protected]] On Behalf Of Hamilton Verissimo de Oliveira Sent: den 29 september 2011 22:44 To: Henrik Feldt; [email protected] Subject: RE: New Castle.IO project? Go for it Sent from my Windows Phone _____ From: Henrik Feldt Sent: 9/29/2011 12:45 PM To: [email protected] Subject: RE: New Castle.IO project? What does hammett think? Green light? From: [email protected] [mailto:[email protected]] On Behalf Of Sebastien Lambla Sent: den 29 september 2011 16:14 To: G. Richard Bellamy; [email protected] Cc: Bertrand Le Roy; Henrik Feldt Subject: RE: New Castle.IO project? Well no because o.exe is separate from everything else, we've had issues before because of that. It's all rather complicated. What I discussed with Henrik was to migrate to a common codebase while preserving some of the existing assemblies and namespaces on my side, using some sort of templating. I'm gonna have to re-review those plans end of next week so maybe I'll find a better way to solve this. From: G. Richard Bellamy [mailto:[email protected]] Sent: 29 September 2011 14:51 To: [email protected] Cc: Sebastien Lambla; Bertrand Le Roy; Henrik Feldt Subject: Re: New Castle.IO project? Sebastian, So, you've got a hard dependency on the OpenFileSystem namespace because you've got deployed o.exe users, and o.exe doesn't autoupdate? Am I missing something here? If they're 1.0 users, then won't they just retain the assemblies used by o.exe, and when they upgrade, couldn't you change the dependency tree? Isn't this equivalent to removing an old, and then adding a new dependency? -rb On 9/29/2011 5:46 AM, Sebastien Lambla wrote: +1 but I'm stuck with OpenFileSystem as a namespace / name, openwrap 1.0 depends on it and the shell doesn't auto-update, changing names would break my installed based which is not ideal. From: Bertrand Le Roy [mailto:[email protected]] Sent: 28 September 2011 22:55 To: Henrik Feldt; [email protected]; Sebastien Lambla Subject: RE: New Castle.IO project? +1 obviously J From: Henrik Feldt [mailto:[email protected]] Sent: Wednesday, September 28, 2011 1:24 PM To: [email protected]; Bertrand Le Roy; [email protected] Subject: New Castle.IO project? Hello everybody, I'm merging open file system and fluent path into what was Castle.Transactions for the transactional file systems' benefit. But it's not so smooth to have it coupled to the transactional behavior - one would have to know both projects to change one, and the IO project is becoming large. Can we create a new project Castle.IO? This would also involve Sebastien Lambla and Bertrand Le Roy who are the authors of openfilesystem and FluentPath respectively - it would be great if they would be allowed to push to this specific repository. I generally think it's a good thing to work together with other OSS projects and cooperate with them, which is why I'm not re-doing their work but asking them to work with me. What do you think? Cheers, Henrik PS, features for this project: * Transactional file system * Non-transactional file systems on Windows * Same for *nix-systems * A fluent API for these systems through both interfaces and extension methods on these interfaces * Long path support (no more >245 chars exceptions) -- 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] <mailto:castle-project-devel%[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. -- 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.
