[ADD] doc: new documentation, with training tutorials, and new scaffolding

1 files changed, 0 insertions, 71 deletions

diff --git a/doc/03_module_dev_06.rst b/doc/03_module_dev_06.rst
deleted file mode 100644
index f6771bbabed..00000000000
--- a/doc/03_module_dev_06.rst
+++ /dev/null
@@ -1,71 +0,0 @@
-.. _module-dev-versioning:
-.. _module_versioning:
-
-=================
-Module versioning
-=================
-
-OpenERP has been developed with modularity in mind: OpenERP should be flexible
-enough so it can be adopted by any enterprise, of any size and in any market.
-By using modules one can adapt OpenERP in many different ways: from completely
-different business to smaller, company-specific changes.
-
-As modules (and the core framework itself) evolve, it is necessary to identify
-modules by their version so a sensible set of modules can be chosen for a
-particular deployment.
-
-There are two trends re-inforcing each others. Firstly OpenERP s.a. will work
-on a smaller number of official modules and let the community handles more and
-more development. Secondly all those modules will receive greater exposure on
-`OpenERP Apps`_ where each module will be owned by a single author.
-
-The solution advocated by OpenERP is straightforward and aims to avoid the
-`dependency hell`_. In particular we don't want to deal with versioned
-dependencies (i.e. a module depends on a specific version of another module).
-
-For each stable release (e.g. OpenERP 6.1, or OpenERP 7.0) or, said in other
-words, for each major version, there is only one (major) version of each
-module. The minor version is bumped for bug fixes but is otherwise not
-important here.
-
-Making variations on some business needs must be done by creating new modules,
-possibly depending on previously written modules. If depending on a module
-proves too difficult, you can write a new module (not a new _version_). But
-generally Python is flexible enough that depending on the existing module
-should work.
-
-For the next major version, refactoring modules can be done and similar
-functionalities can be brought together in a better module.
-
-.. _`OpenERP Apps`: http://apps.openerp.com/
-
-.. _`dependency hell`: http://en.wikipedia.org/wiki/Dependency_hell
-
-Example
-=======
-
-Whenever a new module is developed or must evolve, the above versioning policy
-should be respected.
-
-A particular concern one can face when deploying OpenERP to multiple customers
-is now detailed as an example to provide a few guidelines. The hypotethical
-situation is as follow. A partner needs to create a new module, called ``M``, for a
-customer. Shortly after (but still within a typical OpenERP release cycle, so
-there is no chance to bump the version number except for bug fixes), ``M`` must be
-adapted for another customer.
-
-The correct way to handle it is to leave ``M`` as it is and create a new module,
-say called ``X``, that depends on ``M`` for the second customer. Both modules have the
-same version (i.e. 6.1 or 7.0, targeting the corresponding OpenERP version).
-
-If leaving ``M`` as it is is not possible (which should be very rare as Python
-is incredibly flexible), the ``X`` module for the new customer can depend on a
-new module ``N``, derived from ``M``. At this point, ``N`` is a new,
-differently named module. It is not a ``M`` module with a increased version
-number. Your goal should be to make ``N`` as close as possible to ``M``, so
-that at the next version of OpenERP, the first customer can switch to ``N``
-instead of ``M`` (or include the changes in a new version of ``M``). At that
-point you are in the ideal situation: you have a module ``N`` for one customer,
-and a module ``X`` depending on N to account for the differences between those
-two customers.
-