doc/03_module_dev_06.rst

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