Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,123 | Comments: 45,465

filter by tags archive

Running on the Trunk

time to read 2 min | 293 words

I am one of those fellows that tend to run on the trunk.

What does it mean?  It means that I am using the latest version of the source for my projects. So, I am on the trunk for Boo, NHibernate and Castle (which can be tricky, since Castle isn't on NHibernate trunk).

This has significant advantages for an active OSS project, NHibernate's trunk has the multi criteria support, MonoRail's trunk has the testing support, and since stuff is moving in response to the needs of the users, it is evolving fast. Sean Chambers was impressed by how fast this can happen in many cases. (In others, it is a slower process, but still mostly visible.)

There are some disadvantages, people (recently it was mostly me, sadly) can break the trunk, or commit functionality that breaks your code. In general, I have not found this to be the case for the projects that I am working on. A lot of the committers are running on the trunk as well, and there is a big pressure to make sure that the trunk is stable (ready to ship) because I, at least, do ship from it.

The major disadvantage here, from my point of view, is using a piece of code that is still under development or review. The recent case was Criteria cloning in NHibernate, which has gone through some modifications to get to its current form. Personally, I don't find it onerous to do so, and those are usually rare.

The big advantage is that you get continiously improvements. I does reviews of the changes every now again (now limited to scanning the logs and looking at what has changed) and it keep amaze me how much good stuff is going in there.


Adam Tybor

Running the trunks here too :)

I wish there was an easier way to manage dependencies between projects. Its a pain to maintain my own minor Castle changes because it is stuck using NH 1.2GA.

Ayende Rahien

svn external is one way of doing it, but I am making significant changes rarely enough that it is not much of a pain.

Dan Goldstein

I'm curious why don't these projects release more often if the trunk is stable enough for use? Castle took 10 months between RC1 and RC2, which is a long time to wait for an update for someone who doesn't run on the trunk.


From someone who uses the software, honestly it's makes it very difficult to keep up to date all the time.

So, you'll write about something that isn't available, etc...

I agree totally with Dan and wish there were more recent releases.

Why have a 'RC' when you have trunk that everyone uses instead...(which means I have to pull down source code, build, etc... when all I want to do is use the product, not modify it)

It's good you are on the cutting edge, your a developer on the team :) I'm just saying the people using the parts of it don't always do this - ie. I'm in the middle of developing a solution for a customer and don't want to be in constant flux on some parts I consider to be rock solid

Sean Chambers

Thanks for the link Ayende!

For a long time I tried staying away from the trunk for the reasons you posted above. After awhile though, I broke down and started running off the trunk as there was significant improvements to the codebase that I wanted to leverage, testing support being the crown jewel.

In addition to getting the added support of running from the trunk, you also get any patches that were applied since the last RC, which from my point of view is worth it.

I have yet to run off NHibernate's trunk, as 99% of the features in the GA suffice in what I need.

Tim Scott

Running on the NHibernate trunk has seemed unavoidable for some time -- what with the ICriteria functionality trickling out. That's no a slam on the NHib folks. God bless 'em for getting what they could out as soon as they could! No sooner do I need some feature (like outer joining), and wham is shows up in the trunk.

Ayende Rahien


The reason we don't release more often is that there is usually no pressure for this.

You see CTP and stuff like that from closed source projects, because they need this kind of visibility, there is more of a need to do official stuff.

Beyond that, releasing a project is non-trivial in the amount of time that it takes. Documentation, setup, etc are all things that takes time, and that time has to come from somewhere.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: You want all the data, you can’t handle all the data - 3 days from now
  2. The design of RavenDB 4.0: Making Lucene reliable - 4 days from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 5 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 6 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 7 days from now

And 13 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (12):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats