Have we decided to dump sf.net and upload packages to github instead? I'm asking because github automatically creates packages from tagged versions and I think it would be nice to also have the bin package there, all in one place. Eg. https://github.com/castleproject/Castle.Windsor/downloads
Cheers John On Apr 28, 7:02 am, "Henrik Feldt" <[email protected]> wrote: > Perhaps we could make it into a ruby gem? > > I wrote this > (https://github.com/haf/Castle.Services.Transaction/blob/develop/rakef...) > task today -- it could be turned into this gem perhaps? > > > > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of hammett > Sent: den 26 april 2011 23:37 > To: [email protected] > Subject: Re: Our build scripts, nuget, openwrap and related stuff > > 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 > > ... > > 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.
