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.
