Just to cross-share some experience from Mono packaging for Debian/Ubuntu into Castle. Mirco Bauer just blogged on the reasoning for "The Big Split" http://www.meebey.net/posts/the_big_split_mono_2.10_debian_packaging/ . Summarizing it, Mono will be packaged from now on, on the basis of "ONE managed library per package" so that independently from the set of managed apps that you install no "surplus" dlls and related dependency trees (managed and native) are installed because they were packaged together with something that was needed, obviously there are meta-packages like mono-complete which install all the packages and the packagers do build everything from an specific snapshot of the whole source tree for Mono and each managed app.
To the practical point, with NuGet (or OpenWrap) we can package things very granularly, and have the dependencies sort things for the user (programmer), and we already do kind of it, but we need to use it ourselves, breaking the ties from referencing directly lots of projects in one solution and referencing released versions of our own packages (or test versions from a NuGet repo tied to Team City). With that we will lose the ability to make big refactorings across the whole stack, but that may be, in essence, a GOOD thing, so that we are more conscious on API/Semantics breakages. That leeds to what really will remain complex, dependency versioning, or how to set MaxVersion on dependencies (MinVersion is trivial). My suggestion: to adopt an even more strict policy on version numbers versus API/Semantics breakage: Change the Minor and/or Major version when API/Semantics change, so set MaxVersion to an arbitrary high release number on (build numbers should never matter) . Example: Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.0.1000). If you need to change a signature method on some Castle.Core interface/public class (even specifying optional parameters/default values, or changing parameter names, now qualify as such) them you bump to 3.1.0 and have to build new dependent versions of up-in-the-stack libraries . The remaining question is if some client library isn't affected by that API breakage (lots of test coverage needed to assert that), if we just compile a new version extending the version range on the dependency bumping just the release number, or we have to bump the minor, because of cascading dependencies breakage. Example Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.1.1000). -- or -- Castle.Windsor (3.1) depends on Castle.Core (3.1.0 to 3.1.1000). What NuGet lacks is some kind of smart-updates, it is all-or-nothing about updates, which keeps this decision messy... Anyway what I'm saying is: we have to use NuGet-dependency ourselves to make it work well for our users, too. Just my 2 inflated-cents, Rafael "Monoman" Teixeira --------------------------------------- "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" Isaac Asimov US science fiction novelist & scholar (1920 - 1992) On Tue, Apr 26, 2011 at 8:56 PM, John Simons <[email protected]>wrote: > The reason we run into this issues is because the project separation is > really only separate VS solutions for each main project. > > If we go the next step and completely unmarry the projects from each other, > this means not looking at Castle as a package but instead looking at > Windsor, AR, ... on their own, maybe then we do not run into this issue. > But then what is Castle? > > Maybe the solution is to have combined releases + doco? > > Cheers, John > > On 27/04/2011, at 9:27, Henry Conceição <[email protected]> wrote: > > > It has some pro and cons. > > > > The isolation is good when you think that you're not tied to the other > > projects, specially for releases. But when you try to put all the > > pieces together, it sucks due dll version hell issues. > > > > Cheers, > > Henry Conceição > > > > > > > > On Tue, Apr 26, 2011 at 6:37 PM, hammett <[email protected]> wrote: > >> Isn't this a good time to also make an assessment of the project > >> separations? Specifically having all project separated in github. Does > >> it make life harder/easier? > >> > >> 2011/4/26 Krzysztof Koźmic <[email protected]>: > >>> That sounds good to me, > >>> > >>> We'd need to write the "release" scripts pretty much from scratch > anyway so > >>> we might as well do it in RAKE since as you pointed out there's no need > to > >>> have it run elsewhere than on the build server. > >>> > >>> krzysztof > >>> > >>> On 26/04/2011 10:49 PM, Roelof Blom wrote: > >>> > >>> IMHO MSBuild is not really suitable for creating nuget, packaging, > releasing > >>> to SF etc. > >>> As these tasks are only executed by the TeamCity server and/or > committers > >>> rake with Albacore will make this a lot easier and workable. > >>> There are of course ways to get MSBuild to do this (like creating a > nuget > >>> package with NuGet.MSBuild) it's really throwing in more and more XML > for no > >>> apparent benefit. > >>> A combination of "front-end" MSBuild scripts like we have now and a > >>> "back-end" rake script looks best to me. > >>> This way there's no barrier to open and build our projects locally > like > >>> they can now, and the rest can just script and automate anything that > comes > >>> to mind with a tool well suited for it. > >>> -- Roelof. > >>> > >>> 2011/4/25 Krzysztof Koźmic <[email protected]> > >>>> > >>>> I haven't looked beyond putting Nuget package for Windsor 2.5.3 out, > >>>> something that was frequently requested. > >>>> > >>>> I would *love* to have the release process automated (to a point where > I > >>>> git push to a new tag and our TeamCity recognizes that, and runs a > release > >>>> build that does everything, including release packaging, releasing to > SF, > >>>> nuget and OW, branching (if new branch is needed, that is it's not a > point > >>>> point release and few other things I forgot, like updating the website > in > >>>> all 3 places.)) > >>>> > >>>> I *strongly* prefer giving MsBuild a fair shot before trying any other > >>>> build solution, mostly because MsBuild is out of the box, it's .NET > and many > >>>> developers will flat refuse to install Ruby in order to build a .NET > >>>> project. > >>>> > >>>> I think the scripts we have are really well and cleanly written and > while > >>>> I'm nowhere near as proficient at working with them as Roelof is, I've > been > >>>> able to tweak them on several occasions, same as I'm sure everyone > else on > >>>> the team would be. > >>>> > >>>> This however reminds me of another problem I've had, and we'll > continue > >>>> having, that is keeping consistency in build scripts among projects. > >>>> I've mostly worked with Core and Windsor and all changes and tweaks > >>>> introduced in one project had to be manually copied to the other one. > As we > >>>> have many more projects I'm sure trying to deploy changes to build > process > >>>> all across the board would be nothing short of a nightmare. > >>>> > >>>> Can we please consider some options for automated sharing the build > files > >>>> among all of our projects so that we only change things once and that > change > >>>> gets propagated to every project? > >>>> > >>>> I think it might also be beneficial to have a wiki page that > >>>> a) documents how our build works and how it should be used > >>>> b) documents customizations we've made to .csproj files so that it's > easy > >>>> to add a new project and get it to work with the build > >>>> > >>>> Krzysztof > >>>> > >>>> > >>>> On 25/04/2011 7:49 PM, John Simons wrote: > >>>> > >>>> I would much rather use rake then msbulid. > >>>> No offence to Roelof but currently I think the only person that can > >>>> maintain those scripts is him and I don't believe this is a good > situation. > >>>> I think Krzysztof is trying to hook up nuget and ow to our build + > automate > >>>> most of it, how is that going? Is msbuild working for this? > >>>> Cheers, John > >>>> On 25/04/2011, at 5:36, Henry Conceição <[email protected]> > wrote: > >>>> > >>>> About the build: I don't like the ideia of obligating everyone to have > >>>> ruby + rake in order to build the tx stuff. Probably we will restore > >>>> the msbuild and get rid of the rake scripts when we merge the changes > >>>> on the master repo. > >>>> > >>>> On the 3.5 matter: At least for me, we can drop de support for it. > >>>> > >>>> > >>>> > >>>> Cheers, > >>>> Henry Conceição > >>>> > >>>> > >>>> > >>>> On Sat, Apr 23, 2011 at 12:44 PM, Henrik Feldt <[email protected]> wrote: > >>>> > >>>> Yup, a merge it is. They are merged in my repository now. > >>>> > >>>> > >>>> > >>>> The rest in this letter is about the upcoming alpha. > >>>> > >>>> > >>>> > >>>> Docs: > >>>> > >>>> I have added docs to the wiki as well on my repo. > >>>> > >>>> > >>>> > >>>> Building: > >>>> > >>>> Both projects have been rewritten, based on the previous ideas. This > >>>> > >>>> includes using rake for the build – using it makes me about 10 times > as > >>>> > >>>> productive when writing the scripts. > >>>> > >>>> > >>>> > >>>> Versioning: > >>>> > >>>> In the rake scripts I have set up build-number versioning like that > >>>> > >>>> NHibernate uses, so that > >>>> > >>>> 100x is alpha > >>>> > >>>> 200x is beta > >>>> > >>>> 300x is rc > >>>> > >>>> 4000 is ga. > >>>> > >>>> > >>>> > >>>> So e.g., currently I’m building 2.9.9.11215 at 3 pm, or 2.9.9.1001 for > the > >>>> > >>>> first alpha. > >>>> > >>>> > >>>> > >>>> The versioning for private builds uses the day of the year and the > hour as > >>>> > >>>> the build number. > >>>> > >>>> > >>>> > >>>> Sadly: > >>>> > >>>> Right now I’m just working against .Net v4.0. There’s no real problem > >>>> > >>>> re-targeting 3.5. > >>>> > >>>> > >>>> > >>>> Code contracts: > >>>> > >>>> I’ve done both with MS code contracts for good or bad, but only debug > >>>> builds > >>>> > >>>> have the contracts. In my opinion it’s nice for showing intent around > >>>> > >>>> interfaces. The most prominently used part is that of the static > >>>> > >>>> verification, the part which doesn’t compile into the assembly. I > believe > >>>> > >>>> they work very well with unit tests as well, as one only tests allowed > >>>> > >>>> functionality as opposed to disallowed functionality that throws > >>>> exception. > >>>> > >>>> > >>>> > >>>> People use the debug build with contract assertions or the release > build > >>>> > >>>> without any alterations. > >>>> > >>>> > >>>> > >>>> Alpha TODO: > >>>> > >>>> Finish build script for building nuspecs with lib and tools. Perhaps a > >>>> > >>>> transform file for adding AutoTx and the new NHibernate Facility to a > web > >>>> > >>>> site. Test this out and release 2.9.9 (perhaps). Set up a build server > for > >>>> > >>>> the new rake scripts. Does castle have one that I can use for testing > – > >>>> > >>>> TeamCity? I can create its configs. > >>>> > >>>> > >>>> > >>>> Release 3.0 TODO File Transactions: > >>>> > >>>> I’m aiming to spend a few hours on the file transactions before > release to > >>>> > >>>> fully integrate it with ITxManager, but the non-file transaction parts > >>>> seem > >>>> > >>>> OK. > >>>> > >>>> > >>>> > >>>> Release 3.0 TODO Forking: > >>>> > >>>> There is also a bit of problems related to continuation passing when > >>>> forking > >>>> > >>>> dependent transactions through the new [Transaction(Fork=true)] > >>>> > >>>> functionality as tasks are awaited on the finalizer thread if > exceptions > >>>> are > >>>> > >>>> not observed on the main thread. > >>>> > >>>> > >>>> > >>>> Release 3.1 TODO Retry policies etc: > >>>> > >>>> This idea is something I’d like to investigate: possibly retrying > failed > >>>> > >>>> transactions through the transaction interceptor. Also, creating a > >>>> > >>>> IHandlerSelector for choosing transient lifestyle components if in no > >>>> > >>>> ambient transaction. > >>>> > >>>> > >>>> > >>>> Cheers > >>>> > >>>> Henrik > >>>> > >>>> > >>>> > >>>> From: [email protected] > >>>> > >>>> [mailto:[email protected]] On Behalf Of Krzysztof > >>>> Kozmic > >>>> > >>>> Sent: den 15 november 2010 02:30 > >>>> > >>>> To: [email protected] > >>>> > >>>> Subject: Re: Castle.Services.Transaction + Castle.Windsor? > >>>> > >>>> > >>>> > >>>> Henrik, > >>>> > >>>> What's the status of this? Did you go ahead with the merge? Do you > still > >>>> > >>>> plan to? > >>>> > >>>> From another department - would you care to have a look at the > >>>> documentation > >>>> > >>>> and expand it to fully cover all functionality of the facility? > >>>> > >>>> http://stw.castleproject.org/Windsor.ATM-Facility.ashx > >>>> > >>>> Krzysztof > >>>> > >>>> On 23/09/2010 8:52 PM, Henrik Feldt wrote: > >>>> > >>>> Hello everyone, > >>>> > >>>> > >>>> > >>>> I’m considering merging the code of Castle.Services.Transaction with > >>>> > >>>> Castle.Facilities.AutomaticTransactionManagement/AutoTX. This would > >>>> > >>>> introduce a dependency on Castle.Windsor for > Castle.Services.Transaction. > >>>> > >>>> (Another way of saying it is that the IoC-container would be required > for > >>>> > >>>> using the transactions project, which it is not now. However, it could > >>>> > >>>> simplify versioning/dll-management slightly). > >>>> > >>>> > >>>> > >>>> As of now it is merely a thought: please tell me what your opinions > are on > >>>> > >>>> whether to merge them or not! > >>>> > >>>> > >>>> > >>>> Kind regards, > >>>> > >>>> Henrik > >>>> > >>>> -- > >>>> > >>>> You received this message because you are subscribed to the Google > Groups > >>>> > >>>> "Castle Project Users" 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-users?hl=en. > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> You received this message because you are subscribed to the Google > Groups > >>>> > >>>> "Castle Project Users" 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-users?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. > >>>> > >>>> -- > >>>> 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. > >>> > >> > >> > >> > >> -- > >> Cheers, > >> hammett > >> http://hammett.castleproject.org/ > >> > >> -- > >> 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. > > -- 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.
