Henrik, I didn't called you fly by night. I said that the policy was adopted to prevent it.
About the rake build & changes: I said that probably they would be probably lost when (and if you desire to) the changes will be merged on them tx master repo. What you do on you personal repo it's up to you. Cheers, Henry Conceição On Mon, Apr 25, 2011 at 1:20 PM, Henrik <[email protected]> wrote: > It's not a discussion about a TeamCity configuration that builds to > public releases even, so there's even no potential harm in it. I > wouldn't be able to release any code using it. > > If you wish to call me a 'fly by night' contributor, then those are > your words, not mine. It's slightly off beat to hear you talk about > how to revert any change I do on my own without even considering it. > > On Apr 25, 4:30 pm, Henry Conceição <[email protected]> wrote: >> Hi Henrik, >> >> I'm not reluctant to give you access. As I did explain to you, only >> committers have access to the Castle's git, teamcity and stuff. You >> can see this as bureaucracy, but having this more hardened policies >> protects the project from fly by night contributors and privileges >> meritocracy. >> >> Cheers, >> Henry Conceição >> >> >> >> >> >> >> >> On Mon, Apr 25, 2011 at 11:08 AM, Henrik <[email protected]> wrote: >> > I have worked a lot with MSBuild in my professional projects and I >> > have the firm opinion that XML is not a programming language, and >> > should hence not be used like it is. By saying that exec is the way >> > out of the mess is to completely discard any remaining credibility of >> > the build tool. >> >> > Build tools do dirty-checking, cleaning, clobbering, dependency >> > checking, parallelization, status tracking and much more. MSBuild is >> > in my opinion too verbose and hard to use -- and this is after >> > spending a lot of time with it and knowing its ins and outs. >> >> > Rake/Ruby is extensible at its core and has a lot of momentum in the >> > remaining ALT.Net circles. >> >> > The way I have set up the build scripts; if you read the code; is in a >> > way that makes it possible to have team-city recognize and do all the >> > things you mention. I have experience with TeamCity and rake from >> > other projects as well and I have asked Henry to get access so that I >> > can set it up, but he's reluctant to give me any rights to solve the >> > problem. >> >> > On Apr 25, 12:13 pm, Krzysztof Koźmic <[email protected]> >> > wrote: >> >> 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] >> >> > <mailto:[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] >> >> >> <mailto:[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]> >> >> >>> [mailto:[email protected]] On Behalf Of >> >> >>> Krzysztof Kozmic >> >> >>> Sent: den 15 november 2010 02:30 >> >> >>> To: [email protected] >> >> >>> <mailto:[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] >> >> >>> <mailto:[email protected]>. >> >> >>> To unsubscribe from this group, send email to >> >> >>> [email protected] >> >> >>> <mailto:[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] >> >> >>> <mailto:[email protected]>. >> >> >>> To unsubscribe from this group, send email to >> >> >>> [email protected] >> >> >>> <mailto:[email protected]>. >> >> >>> For... >> >> read more » > > -- > 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.
