Hi,
Status updates. I've sent pull requests to github.com/castleproject for my own projects. If there is anything blocking everyone from releasing that now, I would like to know, or otherwise, if committers would build it and publish it on the web site, I would be grateful. If there are any other things which are git-specific in terms of releasing, please discuss them in this thread. In any way, the release guide needs a complete rewrite, including separation of what people with access to /castleproject can and cannot do. About the status of tagging and versioning. Tag 1.2.0 of core, which is my main dependency isn't building. Try checking it out and doing nant in the root, yourself. Suggestions: . Let git tags correspond to released versions. Never backtrack on these or release "another" tag as the same version. Right now I'm working on the coherent tree. Afaik DynProx was merged with C.Core, so perhaps another build of all projects against a newly tagged 1.4 version would be in order? The coherent tree is built with git submodules which go against specific hashes of the respective code trees. In this way, if all projects are tagged appropriately and this is reflected by the tags of the submodules it would be easier to track dependencies. . Let's move away from binary dependencies. Code is code, so if we specify that C.Components.DictionaryAdapter depends on C.C.Binder 2.3 and C.Core 1.4, this should be true for the code tagged in that way; so C.C.DA could have a structure /lib/C.C.Binder, /lib/C.Core where both of these folders are submodules against the tagged versions. >From this we can say, if the tagged submodules for C.C.DA is not the same as those specified in one of the coherent trees, it's an error from the part of the developer of C.C.DA, and should be fixed. A checkout of a project would then just be to do a $ git pull git://github.com/haf/Castle.Core.git haf-Castle.Core and then $ git checkout 1.3.0 $ git clean -f -d $ git submodule update --recursive . Let's synchronize tagged versions with /Settings.proj This way there is no confusions between what versions really fit well together. Our aim is not to provide 100% backwards compatibility like MS does. Buxfixes would only update assembly file version, but would not affect public interfaces and would be tagged as a build update (i.e. 1.2.5 -> 1.2.5.1), so the public version AssemblyVersion would still be the same. The coherent tree project would be updated to match this new version/hash, giving rise to another tree (DAG) which works. What do you think about this? Regards, Henrik -- 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.
