doc/module-versioning.rst

   1 .. _module_versioning:
   2
   3 Module versioning
   4 =================
   5
   6 OpenERP has been developed with modularity in mind: OpenERP should be flexible
   7 enough so it can be adopted by any enterprise, of any size and in any market.
   8 By using modules one can adapt OpenERP in many different ways: from completely
   9 different business to smaller, company-specific changes.
  10
  11 As modules (and the core framework itself) evolve, it is necessary to identify
  12 modules by their version so a sensible set of modules can be chosen for a
  13 particular deployment.
  14
  15 There are two trends re-inforcing each others. Firstly OpenERP s.a. will work
  16 on a smaller number of official modules and let the community handles more and
  17 more development. Secondly all those modules will receive greater exposure on
  18 `OpenERP Apps`_ where each module will be owned by a single author.
  19
  20 The solution advocated by OpenERP is straightforward and aims to avoid the
  21 `dependency hell`_. In particular we don't want to deal with versioned
  22 dependencies (i.e. a module depends on a specific version of another module).
  23
  24 For each stable release (e.g. OpenERP 6.1, or OpenERP 7.0) or, said in other
  25 words, for each major version, there is only one (major) version of each
  26 module. The minor version is bumped for bug fixes but is otherwise not
  27 important here.
  28
  29 Making variations on some business needs must be done by creating new modules,
  30 possibly depending on previously written modules. If depending on a module
  31 proves too difficult, you can write a new module (not a new _version_). But
  32 generally Python is flexible enough that depending on the existing module
  33 should work.
  34
  35 For the next major version, refactoring modules can be done and similar
  36 functionalities can be brought together in a better module.
  37
  38 .. _`OpenERP Apps`: http://apps.openerp.com/
  39
  40 .. _`dependency hell`: http://en.wikipedia.org/wiki/Dependency_hell
  41
  42 Example
  43 -------
  44
  45 Whenever a new module is developed or must evolve, the above versioning policy
  46 should be respected.
  47
  48 A particular concern one can face when deploying OpenERP to multiple customers
  49 is now detailed as an example to provide a few guidelines. The hypotethical
  50 situation is as follow. A partner needs to create a new module, called ``M``, for a
  51 customer. Shortly after (but still within a typical OpenERP release cycle, so
  52 there is no chance to bump the version number except for bug fixes), ``M`` must be
  53 adapted for another customer.
  54
  55 The correct way to handle it is to leave ``M`` as it is and create a new module,
  56 say called ``X``, that depends on ``M`` for the second customer. Both modules have the
  57 same version (i.e. 6.1 or 7.0, targeting the corresponding OpenERP version).
  58
  59 If leaving ``M`` as it is is not possible (which should be very rare as Python
  60 is incredibly flexible), the ``X`` module for the new customer can depend on a
  61 new module ``N``, derived from ``M``. At this point, ``N`` is a new,
  62 differently named module. It is not a ``M`` module with a increased version
  63 number. Your goal should be to make ``N`` as close as possible to ``M``, so
  64 that at the next version of OpenERP, the first customer can switch to ``N``
  65 instead of ``M`` (or include the changes in a new version of ``M``). At that
  66 point you are in the ideal situation: you have a module ``N`` for one customer,
  67 and a module ``X`` depending on N to account for the differences between those
  68 two customers.
  69