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
<mailto:[email protected]>
[email protected].
To unsubscribe from this group, send email to
<mailto:[email protected]>
[email protected].
For more options, visit this group at
<http://groups.google.com/group/castle-project-users?hl=en>
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.

Reply via email to