This reflects the change in the repo URL.

Oscar is in production at major companies, and has proven itself in all
kinds of scenarios. It's time the version number acknowledges that.

This means there never will be a 0.8 final release; only betas were
released as 0.8 version.

* Add note for __all__ imports to release notes
* Add note on likelihood of Django 1.6 support being removed sooner than
  later

This commit removes a few long deprecated bits in the docs and in
code. It also updates the
release notes to include those removals, and highlights what has been
deprecated in 0.8. And it fixes a Sphinx warning when building the docs.

Changes include:

- New section on organisation
- General moving round of sections, especially around backwards
  incompatibilities
- Various copy changes

Have tested on sandobx site seems all working,
not sure if you need more testing on it.

Fixes #1541.

This changeset adjusts `build_submission` to include the billing address.
This also requires changes to a few method signatures to handle the
billing address explicitly.

This only works when the billing address is stored in the session (as
that's where it is looked up from when building the submission data in
`build_submission`). In many cases (such as Oscar's demo site), we don't
store the billing address in the session - instead, it is captured via
the payment-details forms. Hence, the billing address will still need to
be explicitly set within the submission data.

Fixes #1508

It's necessary to add South before running migrate to successfully
create the database.

Cherry-picked by @maikhoepfel from #1545.

From 4af10d9acd

During many payment flows, the user is able to cancel the process.
This should often be treated differently from a payment error,
e.g. it might not be appropriate to offer to retry the payment.

This exception adds gives us a good way to address that case.

Closes #1528.

pysolr 3.2 has been released. This commit removes the workaround we had
to do to get pysolr 3.1 not failing loudly on Solr 4 error messages.
Instead, we warn the user, and document that one needs to ugprade.

I much prefer just using npm these days.

Currently, a product's stockrecords are used to decide if a user is
allowed to edit a product or not. That doesn't work for parent products,
because they don't have stockrecords. So it's not possible to decide
whether a user is allowed to edit a parent product (and e.g. create
children) for it.

As far as I'm aware, this is not a regression of the
permission-dashboard; I don't think it ever worked. It just hasn't been
spotted because nobody needed it.

This commit also adds some tests to ensure this is enforced.

Had to rename to new method name and re-add a link.

* Fixed a few minor wording issues
* Removed the overview section. I think the "What's new" headlines do a
  good job, and the existing content wasn't really suitable to give a
  nice overview.
* Reduced importance of "Customisation got easier" and "shipping app"
  by moving it further down the list. There's more exciting changes
  in this release, and nobody gets excited about us breaking backwards
  compatibility...
* Add release notes for search changes.
* Drop a random list of explaining product structure, probably a
  copy-paste error
* Moved "cleanup around shipping methods" section into breaking changes,
  because really they are. Also removed a duplicate entry, and the entry
  on the since removed upper_limit field.

I documented 'get_ancestors_and_itself', but the method is called
get_ancestors_and_self.

It was broken without anyone noticing, as reported in #1451. My work in
PR #1441 magically fixed it, but we should still test it.

Fixes #1451.

Also sneakily fixes the wrong URL in the release notes for the previous
commit.

* Document new datetime picker in release notes.
* Update the tests to new format
* Fix some PEP8 issues

Add docstrings to the following classes in 'oscar.apps.shipping.methods':
* Free
* FixedPrice
* TaxExclusiveOfferDiscount
* TaxInclusiveOfferDiscount

Fix typo in 'docs/source/howto/how_to_configure_shipping.rst':
* Change 'shipping.addr' to 'shipping_addr'

It only prevents adding a product to a range; offers can be applied
nonetheless (despite the docs saying otherwise). The same functionality
can be achieved by overriding get_is_discountable, so it can be safely
removed.

From #1435:
CommunicationEventType.category is used also to "detect" order-related
emails, in which case when previewing that email Oscar will put a
user-supplied order in the context for the email template.
This doesn't always work because the string that's saved in category
is localized.

Using choices remedies the problem. I don't think this feature is
commonly used, so no attempt at backwards-compatibility for
non-English setups is made.

South doesn't create a migration for this change.

Fixes #1435.

Registering receivers is a tricky business pre-Django 1.7 as they get
registered at the same time when models get registered, but require the
sending model to already be in the app cache. It's surprising we don't
see more issues!

Recommendations:
* Avoid calls to get_model in modules that get called during app init at
  all cost
* Don't use get_model in your own code. Just import directly.
* Switch to Django 1.7 :)

This commit probably fixes the issue in #1205. But get_model calls to
fetch the category, product image and stock record will all fail,
because receivers listen to their signals.

This commit also moves the catalogue receiver into it's own receivers
module, because that's how we do it elsewhere. That won't make a
difference to the issues though.

Closes #1173

Nothing major to see here. Improved the slightly horrid
TestCreateProductForm test class.

The main issue is that Oscar relies on it's app configs to keep class
loading working. Hence, appropriate app configs need to be created when
upgrading.

A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.

oscar.core.loading.get_model is a thin wrapper around Django 1.6's
get_model function. The latter returns None if the model can't be found,
whereas the Oscar variant loudly failed with an ImportError.
With Django's app refactor, most of that behaviour in Django has been
changed, and Oscar's get_model falls back to Django's
get_registered_model. But the latter raises a LookupError.

To avoid having to catch both errors, Oscar's get_model now raises a
LookupError no matter what Django version is used. This should have
minimal impact on backwards compatibility, as get_model isn't really
used outside of Oscar core.

Both the master branch and Django 1.7 branch introduced a South
migration for offers. It's been addressed by dropping the one introduced
on the Django 1.7 branch, and re-creating it.

The native migrations have been completely recreated.

Copy-paste fail.

This commit updates the Getting started guide and highlights the upgrade
path for Oscar 0.8.

Oscar's policy is to support two versions of Django. So while there
isn't a major reason to drop support for Django 1.5, dropping support
for Django 1.6 once 1.8 is released will reduce complexity considerably.

It is the only model in any of the Oscar dashboard apps. It causes an
issue with the get_model() call, because the dashboard app labels had
to be renamed for Django 1.7. So in Django < 1.7
get_model('ranges', 'RangeProductFileUpload') would work, wheras in
Django 1.7 it had to be get_model('ranges_dashboard',
'RangeProductFileUpload'). There is other ways of solving the problem,
but given that it is a rarely used model of temporary nature, enforcing
that dashboard apps are models-free seems like the cleanest solution.
This only has to be enforced till support for Django 1.6 is dropped, and
I doubt we'll see the need for a model in a dashboard app till then.

This prevents an IntegrityError from slugs clashing after renaming a
range to avoid the checked-for name clash.

Fixes #1424

Most email servers don't respect capitalisation, and many users don't
know about it. So Oscar now does what the rest of the world does, and
ignores the capitalisation when looking up an email address.

Fixes #1179.

Where I previously thought that renaming HTML/CSS is more hassle than
it's worth, @mbertheau convinced me that to update a codebase, a general
search-and-replace is the best approach already and will catch any
HTML/CSS changes.

I also missed to deprecate the min_variant_price properties.

It must be left over from more glorious times.

This is the squashed version of #1369.

Closes #1369.

The Django admin often enough does not work or not as expected; that
isn't communicated clearly enough. This commit hopefully clarifies
things a bit.

I started looking at this because on the mailing list, having the UK as
only shipping country led to confusion. This is mostly due to the
shipping address form hiding the country field if there's only one
country enabled, but all the validation then requiring UK postcodes and
phone numbers.

It's bothered me for a while that we're using a fixture to populate the
countries, which is at risk of becoming stale.
pycountry offers an excellent data source for a list of countries, so I
polished an existing management command to use it to populate the
country database.

This commit has two immediate effects:
* New setups will use a more current country database
* By default, all countries will be marked as shipping countries

pycountry also ships with localised names of the countries, which should
allow us to populate the database with localised country names.

* Added some docstrings because I kept having to look up details
  of the implementation
* Removed index on the alpha3 and numeric code because we never use
  those fields for lookups
* Turned the numeric field into a CharField as suggested

As it came up on the mailing list again, I've clarified a few more
scenarios of what needs to be done with migrations when upgrading.