Currently one can choose between the following OGRE versions
1.9, 1.10, 2.0 and 2.1

However the versioning scheme has become completely arbitrary while still resembling semantic versioning.
As a consequence somebody even had to put a “What version to choose?” guide on the OGRE homepage.

Unfortunately the guide confuses more than it helps:

First of all, forget about 1.9. It lacks most of the bugfixes that are in 1.10 and therefore is less stable. Even if you rely on third-party add-ons – 1.10 is the way to go. The pointless change that broke backward compatibility got reverted in the github fork.
If you do not like tracking a moving target and want stability, go with 1.10. It contains most bugfixes and the existing API does not change. This is actually your only choice if you want to rely on third-party add-ons or have existing code using OGRE. Furthermore you get the largest Platform support including HTML5 and Mobile.
You can mostly forget about 2.0. It is neither backward compatible with 1.10 nor forward compatible with 2.1. One should rather think of it as 2.1 beta (2.0 beta when using semantic versioning).
Feature-wise it boosts the node updating performance by about the factor of 5x by exploiting cache locality (see 1.9 review by Mike Acton). However it lacks many fixes that are in 1.10 and it is unmaintained so things will not improve.
Finally 2.1 is where all the new and shiny things are. However it is backwards incompatible to 1.10 and 2.0 so calling it 3.0 would be more appropriate.
Feature-wise you get the high node updating performance of 2.0 and automatic batching for rendering. The batching results in a higher GPU utilization so with 2.1 rendering speed is bound by the GPU performance. With 2.0 and 1.x on the other hand the GPU was often stalled because of inefficient material and geometry changes. However even 2.1 lacks some bugfixes that are in 1.10 and more importantly it is a moving target as the API still evolves. Also it only works on desktop platforms.

You might wonder why 2.1 while having the latest features, lacks some bugfixes of older releases. Read on..

Lack of branching concept

Usually projects have a default master or trunk branch where all development eventually ends up and optionally some maintenance and bleeding edge branches. See this for a small overview of the according workflows.

Now OGRE has the following branches: v1-9, v1-10, v2-0, v2-1 and default. By common sense default would contain the most recent code while the other branches would be maintenance branches of the respective releases. But not today! Actually all of these branches are under active development with 2.1 containing the latest features and default representing the current stable version. (actually default and 1.10 are pretty much the same)

As there is no clear code flow between the branches this means that branches are diverging. Fixes for issues in one branch do not distribute across the others. Examples:

As you can see we got all possible directions here. The situation can not be easily resolved by successive merging branches into each other.

With the github fork, I therefore manually compared the different branches and cherry-picked all fixed into master (v1-10).

This is why I initially called it the stable fork. Even though it contains new features as discussed in my last post, the API is backwards compatible to existing code/ add-ons and it aggregates all bugfixes in one branch.