Hmm.. tough one. At least OW supports Nuget repositories. Not sure about the other way round..
On Wed, Apr 27, 2011 at 4:59 PM, John Simons <[email protected]> wrote: > Does this mean we need to decide to use either nuget or ow? > Is there a good comparison of both? > > ________________________________ > From: Krzysztof Koźmic <[email protected]> > To: [email protected] > Sent: Thursday, 28 April 2011 9:24 AM > Subject: Re: Our build scripts, nuget, openwrap and related stuff > > Oh, hi Cristian :) > > Go for it mate. > > Krzysztof > > On 28/04/2011 9:23 AM, Cristian Prieto wrote: > > I raise my hand... > Cristian Prieto > > > On Thu, Apr 28, 2011 at 6:05 AM, Hammett <[email protected]> wrote: > > I like the idea. Who's stepping in to make it real, though? > > > On 2011-04-27, at 5:32 AM, Rafael Teixeira <[email protected]> wrote: > > 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. > > -- > 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.
