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.
