This release is the first step in the major refactoring of Tangram,
which is API-backwards compatible.
The differences between 2.09 and 2.10 are limited to namespace re-organisation.
The test suite still succeeds unmodified,
but has been tweaked to suppress warnings that deprecated modules are being used.

Sync release with 2.09.
svk this time made this extremely painful,
but we must forgive it because after all trying to support distributed source management tool atop of a synchronised versioning filesystem is pushing shit uphill.

However,
so long as you use Tangram::Core,
use Tangram or use Tangram::Compat before any of these old names are used,
then @INC magic should be able to catch the inclusion and load the correct module instead.

Added new use Tangram import arguments :core and :compat_quiet.
to be documented.

A very nasty but also obscure bug affecting horizontal mapping and polymorphic retrieval (or aggregation) was reported by Alex.

The fix for it has made remote expressions always include filtering (via WHERE) on the type column as well as the ID column in most queries.
This should not affect the result of queries; it is just passing on an assertion in the code base through to the database back-end.
The times it will affect results are when your currently active schema does not match the one used to create the database and you were previously relying on side-effects.

Examples of the query differences will follow here before the 2.09 release.

This version has broken outer joins; to be fixed in the next release.

Also,
this Changes.pod seems to being delivered to some random place in your @INC; sorry about that,
the next release will exclude it via the appropriate ExtUtils::MakeMaker voodoo.

Tangram::Dump now checks (via $storage->id_maybe_insert()) whether objects that it is saving should be inserted to the DB first,
which allows the practice illustrated by the t/musicstore/ test suite to work.