Readded Scheduler.unschedule_func(), which now raises a KeyError when no matching jobs are found; renamed max_concurrency to max_instances

2 files changed, 17 insertions, 7 deletions

diff --git a/docs/index.rst b/docs/index.rst
index 12d03af..07e26a0 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -196,6 +196,12 @@ scheduler by that name when the scheduler is started, a new job store of type
 :class:`~apscheduler.jobstores.ram_store.RAMJobStore` is created to serve as
 the default.
 
+The built-in job stores are:
+
+* :class:`~apscheduler.jobstores.shelve_store.ShelveJobStore`
+* :class:`~apscheduler.jobstores.sqlalchemy_store.SQLAlchemyJobStore`
+* :class:`~apscheduler.jobstores.mongodb_store.MongoDBJobStore`
+
 Job stores can be added either through configuration options or the
 :meth:`~apscheduler.scheduler.Scheduler.add_jobstore` method. The following
 are therefore equal::
@@ -213,8 +219,8 @@ and::
 
 The example configuration above results in the scheduler having two
 job stores -- one
-(:class:`~apscheduler.jobstores.ram_store.RAMJobStore`) and one
-(:class:`~apscheduler.jobstores.shelve_store.ShelveJobStore`).
+:class:`~apscheduler.jobstores.ram_store.RAMJobStore` and one
+:class:`~apscheduler.jobstores.shelve_store.ShelveJobStore`.
 
 In addition to the built-in job stores, it is possible to extend APScheduler to
 support other persistence mechanisms as well. See the
@@ -247,14 +253,14 @@ directly, since the scheduler has shortcut methods for these built-in
 triggers, as discussed in the next section.
 
 
-Limiting the concurrently executing instances of a job
-------------------------------------------------------
+Limiting the number of concurrently executing instances of a job
+----------------------------------------------------------------
 
 By default, no two instances of the same job will be run concurrently. This
 means that if the job is about to be run but the previous run hasn't finished
 yet, then the latest run is considered a misfire. It is possible to set the
 maximum number of instances for a particular job that the scheduler will let
-run concurrently, by using the ``max_concurrency`` keyword argument when adding
+run concurrently, by using the ``max_instances`` keyword argument when adding
 the job.
 
 
diff --git a/docs/migration.rst b/docs/migration.rst
index 5fce220..ccdb214 100644
--- a/docs/migration.rst
+++ b/docs/migration.rst
@@ -4,6 +4,7 @@ Migrating from APScheduler v1.x to 2.0
 There have been some API changes since the 1.x series. This document
 explains the changes made to v2.0 that are incompatible with the v1.x API.
 
+
 API changes
 -----------
 
@@ -14,9 +15,12 @@ API changes
 * dump_jobs() is now print_jobs() and prints directly to the given file or
   sys.stdout if none is given
 * The ``repeat`` parameter was removed from
-  :meth:`apscheduler.scheduler.Scheduler.add_interval_job` and
-  :meth:`apscheduler.scheduler.Scheduler.interval_schedule` in favor of the
+  :meth:`~apscheduler.scheduler.Scheduler.add_interval_job` and
+  :meth:`~apscheduler.scheduler.Scheduler.interval_schedule` in favor of the
   universal ``max_runs`` option
+* :meth:`~apscheduler.scheduler.Scheduler.unschedule_func` now raises a
+  KeyError if the given function is not scheduled
+
 
 Configuration changes
 ---------------------