doc/03_module_dev_06.rst

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