The point of git is: ---> There IS not master repo! <---- :) That's the beauty of it.
And only the build server would have to have ruby/rake support, the rest can run "msbuild Castle.Services.Transaction.sln". On Apr 24, 9:36 pm, 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.
