The howto recipe on shipping has been rewritten to describe the new
changes to shipping functionality. The old shipping app reference has
been merged in too to avoid duplication.

The non-camelcased class has bothered me for a long time.
We can remove the deprecated spelling for version 1.0 :)

Oscar already has child products to model tightly coupled products, and
"recommended products" to model products that are related (which we
expect to mostly be used for upselling). Product.related_products was a
third option that sat somewhere inbetween, and which I think will often
not be needed, has a mediocre interface in the dashboard and beyond that
no special treatment in the codebase. Furthermore, I see it being
confusing when trying to model a catalogue, and it's easily added back
if necessary.

It just duplicates ProductRecord.score, makes ``oscar_calculate_scores``
slow and generally serves no useful purpose.

Also included docs for the previous changse to
``oscar_calculate_scores``.

Importing things in settings is discouraged. But until now,
OSCAR_SLUG_FUNCTION could only be set as a callable, which requires
importing. It's now been updated to use the import_string function.

Seems like a good practice to define them explicitly.

Cherry-picked from d755aae.

Oscar uses explicit through-models for some ManyToMany relationships.
The expectation is that for each combinatination of the two foreign
keys, only one model can exist. But this hasn't been enforced until now.

Fixes #1309.

This completes the move away from partner wrappers to strategies. All
the methods for determining price and availability information have now
been removed from the partner classes.

The helper policy class ("DelegateToStockRecord") have been removed too
as they no longer have methods to call on the stockrecord.

This couples the methods and their bands together, and allows editing of
all bands in one page.

This was meant to be added in 0.7, but forgotten. Now, the Python,
Django and Oscar version in use are reported if OSCAR_TRACKING is
enabled. This helps Tangent to make informed decisions about what
versions of Python and Django to support, and how long to maintain older
Oscar versions.

The recently introduced management command makes customising easier, and
the docs have been updated accordingly. The how-tos could still do with
updating to the new command, but at least the main docs are current.

I just wanted to change one word, and then got sidetracked with
reordering the sentences.

This finishes the changes made in v0.6 where basket lines started
requiring a stockrecord FK. v0.7 handles the upgrade in middleware by
updating basket lines that didn't have a stockrecord. But since the
patch for v0.7 requires additional database queries, it's time to remove
it - which is what this change does.

This will be a slightly fiddly upgrade for some people as they will need
to run a data migration on their DB before applying the new basket
migration. I've included a sample snippet in the release notes which
should help.

- Rework the page on applying taxes in the US
- Update the release notes
- Update the "sandbox" page with details of the new site

Understanding the application tree these days is only necessary when
wanting to change URLs or views. Hence, it's been moved from the
customising doc and reworked into the how-to. This reduced some
considerable duplication and hopefully makes the customisation section
clearer.

These days, to override a mixin it is only required to override the
OrderPlacementMixin; overriding the app and view is not necessary. It is
just a generic case of overriding a core class. A dedicated how-to is
thus unnecessary.

As overriding a core class is the general goal of any advanced
customisation, it has been merged into the customisation section, which
has been given an overhaul as well.

The section regarding modifying apps will be re-added as part of a
higher-level "the Oscar application tree" kind of document.

It's such a core concept, it deserves a dedicated document. Moved some
of the "why" from the how-to into it as well.

The getting started guide now explicitly mentions copying the "missing
image" image when working with a remote file storage. Was raised in
issue #1314.

Sphinx turned the double dash into a long dash. A user reported issues
with running the command after copy&pasting it.

(cherry picked from commit 90ab1f19f0)

Sphinx turned the double dash into a long dash. A user reported issues
with running the command after copy&pasting it.

They already existed, but were intentionally hidden from the list of
release notes prior to the release of 0.7 to avoid confusion.

It's getting easier and easier to customise parts of Oscar; the
customisation section can do with a rewrite because of it. Added to my
to-do list.

Oscar is slowly adding better support for switching languages on the
fly. That also means that locales need to be switched.

The issue this commit tries to fix is that when switching languages, the
locale for rendering prices doesn't change, and hence prices are
formatted incorrectly.
Oscar used to require hardcoding the locale for prices via
OSCAR_CURRENCY_LOCALE. I'm not sure what the reasoning behind this was,
because as far as I'm aware, the locale can be auto-detected from the
current language. This not only reduces complexity, but nicely works
when switching languages.

Several of Oscar dependencies don't support Windows, some of them don't
work at all. Added a warning that indicates installing Oscar on Windows
is a tricky process.

This allows importing a class or attribute by the reasonably common
string notation, which is useful for e.g. settings. When using settings,
we should prefer absolute imports over using get_class, because that
limits us to modules in INSTALLED_APPS.

Django has issues with using blank=True and unique=True together on a
CharField, which is why we've introduced the NullCharField. A more
detailed description can be found in it's docstring.

The same problems apply to the proxy_class fields on offer models.
Switching them to NullCharFields should resolve the problem.

Also altered one check for proxy_class to be consistent with the other
checks for an empty proxy class.

A check for outstanding migrations brought this up. Unfortunately I
can't find a way to instruct South to ignore the parameter. Model
introspection only allows setting what basically is fancy default
values. Parameters like help_text are ignored in South's
USELESS_PATTERNS, but can't be altered.

* Made upper_limit a DecimalField, like the other weight fields
* Increased default precision for weights to be to the gram level. Will
  be useful for deployments shipping smaller items such as stickers,
  where 10 grams precision is too low.
* Changed strings to official 'kg' abbreviation.