Release Policy Modules

Contents 1 Modules release cycle 1.1 Release dates 2 Modules release process 2.1 Create new module 2.1.1 Naming rules 2.1.2 How to publish and maturity status 2.1.3 Base language of a module 2.1.4 License 2.2 Publish new version 2.2.1 Version numbering 2.2.2 Dependencies 2.2.3 Tag policy 2.2.4 Heads policy 2.2.5 Tests 2.2.6 Api changes 2.2.7 Checklist of steps for publish a new version 2.3 Emergency releases 2.3.1 When the repo has commits that should not be included in the emergency release 3 FAQ 3.1 To which modules applies this policy

Modules release cycle

This apply to all modules maintained or that will be maintained by engineering team.

Release dates

• The last date for merge projects is the same than in erp

• The date for publish in QA is the same date than in erp

• The date for move to QAA is the same date than in erp

• The date for move to CS is the same date than in erp

• In case is urgent to release a new version of a module, this version should be in maturity status test.

Modules release process

This apply to all modules.

Create new module

Introduction to modularity and how to create and package a module

Naming rules

Naming guidelines for modules

How to publish and maturity status

How to publish a Module and maturity status

Base language of a module

Although is allowed that a module has a different base language of English, we strongly recommend use of English.

Internally for openbravo staff is mandatory to use English.

Exception: localization modules don't need to follow this rule.

License

• Community, openbravo staff
  • Include the license header to all the source code files that can have it, you can copy the license form any java of pi repository for example java
  • Set license_type to obpl
  • Set license text to: (you can also copy it from core module)

Licensed under the Openbravo Public License Version 1.1.
You may obtain a copy of the License at http://www.openbravo.com/legal/license.html or in the legal folder of the Openbravo ERP core distribution.

• Commercial
  • Commercial modules needed not only be published but also configured once (i.e. pricing in butler). Ask Dmitry to do this for every new commercial module.
  • Include the license header to all the source code files that can have it, you can copy the license form any commercial repository for example java
  • All commercial modules must have a legal folder in the root folder, and include in the folder a file called OBC_license.txt , you can use this one: https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/file/tip/legal/OBC_license.txt
  • Set license_type to obcl
  • Set license text to: (you can also copy it from any retail module)

Licensed under the Openbravo Commercial License version 1.0
You may obtain a copy of the License at http://www.openbravo.com/legal/obcl.html or in the legal folder of this module distribution.

Publish new version

Version numbering

Increase the major version needs a justification since, it means that breaks the compatibility with all the dependent modules.

So if it is not really needed do not increase the major version.

A typical case when is needed to increase the major version, is when adding a new dependency. Example: module A depends on module B, both already published; then if added to A a dependency to C, when publishing in the forge the new version of A, it will only allow it if is a new major version.

The minor version should be increased by 100 in each release, so there is free numbers if needed to publish an emergency release.

Dependencies

• As general rule:
  • A module must depend on all other modules which are needed to make it work
  • In case that is a specific version of another module is needed as minimum. The dependency needs to ensure this minimum.
• Depend on a version of the erp still not published (commit only in pi)
  • Wait for an integration of the changeset and take the latest CI (Test Maturity) version published in the central repository: link
  • Note: ant check.module.consistency will fail since in your local the version of the erp probably will be less than the version of the dependency, but this case is expected.
• Cascade dependencies, when mod A depends on B, and B on C:
  • As general rule A should not depend in C
  • A should depend on C, for example in the case that needs a more restricted start version of the dependency to C, than the one that already have B to C.

Tag policy

The name of the tag should be the version number of the module.

Example:

hg tag 1.2.345   # note only the version, without any text

Heads policy

As general rule never needed to create a new named branch in the repository.

The current heads is for separate erp 2.50 and 3.0 versions of the modules, so for new modules no need of new heads.

If you found that you need a branch for a module try first if can be managed with a cloned repo of the module, if not check with rm before create a new branch (named head).

Tests

• Compile and jslint tests
  • Every module should have 0 javac command line compile time warnings and 0 jslint warnings.
  • Note: overriding ignoring the warnings is not acceptable as a fix, unless really required.
  • Warnings: Every module should have 0 wad-validation or other warnings showing up during either: compile, package.module or install
• Remember to create the test cases in:
  • Testlink
  • Selenium

Api changes

• api changes in modules

Right now there is not yet implemented an api for modules, but take into account that other modules that depend on your module maybe are using your functions and db objects, so each time that change these things can break the dependant modules.

• api changes in erp

Guide of API Changes in the ERP

When doing an api change in the erp this could break a module, there is available a tarball with all the modules Decide how to manage, if possible fix the modules if not notify the owners

Checklist of steps for publish a new version

• commit the module changes
• Check that all the issues of the module are closed
• Check commits of the module repo not related to any issue (from projects), to see if can be included in the new version
• check / fix dependencies
• increase in one the module (minor) version (module window)
• overwrite the update information text with the last commit message, or a description that explain the fix, since this info is visible in the forge
• export database
• commit the change of version (Typical message: Updated the module version to x.y.z)
• tag the version in the repo ( remember the tag policy )
• package the module (ant package.module -Dmodule=module_java_package)
• push to repo
• upload the module to the forge with test maturity
• Test that installs in a clean environment
• Pass the module to QAA

Emergency releases

For the moment there is no policy about emergencies releases of modules, but handle each case as it appear.

We assume that will be cases when hot fix has to be released, and then we will be publish a new version of the module, earlier than the normal release cycle define (similar to the emergency updates for the erp or retail).

When the repo has commits that should not be included in the emergency release

In this case you can:

• update the repo to the desired version
• do the commit there
• package and publish the emergency (remember that normal releases increase the number by 100 to left numbers for the emrgencies)
• do the merge with the tip of the repo

FAQ

To which modules applies this policy

This apply to all modules maintained or that will be maintained by engineering team, and the next publish of any of these modules must follow this policy.