View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


Release Process



This document describes the different phases of the release engineering process leading up to the actual build and publication of a 3.0 release, both the Community Edition and the Professional Subscription.

Package 1st of each month (normal)

Disable int-promote (normal)

Disable job

Check issues target (normal and emergencies)

Update the release status in aha (normal)

Update the cloud image (normal)

Check for the latest image in [ ubuntu_cloud_images]

cd releaser
# Edit the config file for folder name (yyyymmdd)
# Execute 

Create backport repo (normal)

Create the backport repo for the current release, so pi is not blocked for next release

As apache user in

./ 3.0PRyyQn

Ensure the repo has the needed permissions and is accesible by developers for read and write.

Remove permissions to push backport repo (emergencies)

Before run the package of a emergency release is needed to remove push permissions to the repo , so no new commits come unexpectedly during the process.

ssh -p 19198  -lstaff.rm
staff.rm@code ~ $ su -
code ~ # vi /scm/hg/config/hgrc

[web erp/backports/3.0PRxxQy.z]
#allow_push = @core, @packagers
allow_push =

code ~ # /etc/init.d/apache2 reload

commit the change to the repo e.g:

cd /scm/hg/
hg ci -m "Revoke access to 3.0PR16Q3.5 repo" -u "Rafa Alonso <>"

Run the package (normal and emergencies)

Connect to the releaser

ssh -p19198

Check for disk space

df -h

Remove the old releases in ~/outputs

 cd ~/outputs 
# criteria of release folders to delete
* Not latest emergency releases
* The releases promoted to CS
# Note: Remove old release repos: check the folders in path '~/repos', if the release is published remove it.

Clean the folders from ~/build/*.

cd build
rm -rf 3.0*

For all packages it is needed to create the qa instances, except for the repackages of normal releases, and also it is needed to be careful to not delete the instance that they are using for this normal releases. This is pending to automate.

cd ~/releaser

Normal :

./package 3.0PRyyQn 2>&1 | tee ../logs/package-3.0PRyyQn.log

Emergency :

./package 3.0PRyyQn.o build-qa 2>&1 | tee ../logs/package-3.0PRyyQn.log

Update qa machine (normal)

Start qa-erp (i-f0280b3c) and do system update

/etc/init.d/tomcat stop
apt-get update
apt-get dist-upgrade
apt-get autoclean
apt-get --purge autoremove

If needed, QA will ask for another machine to test update, check with QA if needed an instance with previous QAA or CS release

./build_qa_instance 3.0RRyyQn.o 2>&1 | tee ../logs/build_qa_instance-3.0PRyyQn.log

Modules reminder (normal)

Note: only normal releases, no emergencies. And in the first package. Important: Retail should be also packaged and the merge of release versions merged into pi (pmods) repos of retail should be done

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ package 3.0PRyyQn emails-no
# real run sending the mails to teams
./ package 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-package-3.0PRyyQn.log

After the first notification remind weekly to the teams till done.

Create the automation tag (normal)

cd ~/repos/automation_pi
hg pull -u
hg tag 3.0PRyyQn

Complete list of fixed issues in the PR (normal)

Add the list of issues/features fixed from last MP to the release changelog.

Complete list of fixed issues in the PR (emergency)

1. Get the text about the issues fixed in the release from:

 $ ssh -p 19198 -lstaff.rm
 $ su -

 # /rt/changelog_script/ 3.0PRyyQn.x
 e.g: # /rt/changelog_script/ 3.0PR16Q4.1

2. Edit

Optionally can be checked with roadmap page to ensure that is correct:

Release Notes (normal and emergencies)

Bulbgraph.png   In order to allow developers to write the release notes when they commit some issue/project, the release notes for the next release should be also available.

e.g, for PR16PR4.1

Update API changes wiki (normal and emergencies)

Update the API changes list, as follows:

Email of release notes (normal)

Send an email to team leaders to write the "Fixed issues" section with meaningful messages.

Recipients: Asier Lostale, Eduardo Argal, Victor Martinez, Egoitz, Pablo Sarobe, staff.rm, Dmitry

Email of packaging (normal and emergencies)

Send an email to following this template example:

Subject: 17Q1 Final package (erp and retail)


17Q1 repackaged, QA Machines can be updated via MMC with QA maturity.

Version: 3.0.31087
35371: Wrong orders shown in "Create Invoices From Orders" window

Version: 1.8.2502
35021: Copyright year extend to 2017 for pos hardware manager


Email pi open for next mp (normal)

Send an email to release management list

PI is now open for PRyyQn commits.

The dates for PRyyQn are the usual ones [1].


Second package (normal and emergencies)

Do the package (normal and emergencies)

Run the package

cd ~/releaser
./package 3.0PRyyQn 2>&1 | tee ../logs/package-3.0PRyyQn.v2.log  
Note : If QA request to rebuild the test machine pass 'build-qa' as parameter to package command ./package 3.0PRyyQn build-qa

Update the release changelog

Get the changelog

cat ~/logs/3.0PRyyQn-changelog.log
Example: cat ~/logs/3.0PR17Q1-changelog.log
Add the new issues to Release_Changelog
Note: Check for the issues sorted in ascending order

Email of the package (normal and emergencies)

For announce this change search for previous release mail, and edit it accordingly:

Template (mostly send both erp and retail are sent together


YYQn for erp and retail packaged for testing

erp version : 3.0.<version> - PRyyQn
Changelog :
QA Machine : 

Retail : Version 1.8.<verion> - RRyyQn
Changelog :
QA Machines :

Dummy (normal and emergencies)

When QA ask for a obx to test the update, run in releaser instance:

cd ~/releaser
./build_upload_dummy 3.0PRyyQn 2>&1 | tee ../logs/dummy-3.0PRyyQn.log

Publish (normal and emergencies)

Wait for the Product manager and QA to approve the publishing

Check for 'lost' commit done after last package (normal)

The repository was closed to further pushes when the packaging started, so this step can be skipped.

If for any reason new pushes have been added, stop all publish and check.

Run the publish script (normal and emergencies)

In the releaser machine

ssh -p19198
cd ~/releaser
./publish 3.0PRyyQn 2>&1 | tee ../logs/publish-3.0PRyyQn.log

Verify that the process exits with status 0

Stop QA test machines (normal)

Check with QA and stop the testing machines qa-erp machine

Amazon search

Modules reminder (normal)

Note: only normal releases, do after retail also published, no emergencies

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ publish 3.0PRyyQn emails-no
# real run sending the mails to teams
./ publish 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-publish-3.0PRyyQn.log

After the first notification remind weekly to the teams till done.

API docs

This step is fully automated. The javadoc is created on packaging, uploaded to and its index page is updated.

API check

Ths package/publish is also taking care of re-genearing the api-checks data on every (non-emergency) release and pushes it to api-checks.


Merge to main. Rearrange tags (normal and emergencies)

This step sorts the tags in the repository. Sorted tags are required for other RM scripts to work. No steps required for normal release. No steps required for the last version. You can also verify if the tags must be rearranged, looking at the tags in the repository If the published version is not the first one, rearrange is required.

Partially automated for emergency release publish. Re-ordering of tag is required. Check of the publish script message "NEED to ORDER the releases"

# Manually reorder the entries in .hgtags and .hgsigs
ssh -p19198
cd ~/releaser
hg resolve -a -m
hg ci -m "Merge temporary head for $TAG"
# Check that everything it is fine and push
hg di -r $MAIN_ID
hg out
#hg push

Merge main to pi (normal and emergencies)

NOTE: if publishing a emergency release during release process of a normal release, then not needed to do the merge of tags form main to pi, since when done this merge for the normal release this will automatically done. Is possible to do the merge from main to pi of emergencies without wait to the normal release, but ensure when merging the normal release from main to pi that the tags are correctly merged and none is lost.

1. Merge tags from main to pi:

ssh -p 19198
su - 
su - apache
./ 2>&1 | tee merge-main-pi-3.0PRyyQn.log

2. Verify the merge

cd /tmp/merge_main_pi_erp_temp
hg tags
hg log -G | less

3. Finally

hg push

Create new backport repo in code (emergencies)

Note that the backport repository is created based on main, so, once the publish script has finished, the backport can be created

ssh -p 19198
su - 
su - apache
cd /var/www
./ 3.0PRyyQx.y
e.g: if publishing PR16Q4.1
./ 3.0PR16Q4.2

Restore permissions to the repos

Change permissions

ssh -p 19198
su - 
su - apache
cd /scm/hg/config
vi hgrc
# e.g. for PR16Q4.1
[web erp/backports/3.0PR16Q4.1]
allow_push = @core, @packagers

commit changes to the config repo

hg ci -m "Grant access to PR16Qx.y backport repo" -u <username <email>>

reload apache2 as root

/etc/init.d/apache2 reload

Push the automation tag (normal)

Usually it is not needed to do in emergencies updates

Verify that the changeset is the correct one

  1. check the email of the push that passed try
  2. if any doubt ask QA


cd ~/repos/automation_pi
hg in
# hg pull --rebase
hg out
hg push

SourceForge (normal and emergency if last)

Check the vmware of the current MP is the default download for Openbravo project.

Mantis (normal and emergencies)

Release notes (normal and emergencies)


In 3.0 release notes, add a new entry for the new release, copying another and updating the links

Add CS date to calendar (normal)

Add to calendar the day to pass CS, it is fixed date, the last day of moth in two months after the publish in qaa.


Email (normal and emergencies)

need to be sent to

Xavier Places <>, Pablo Rueda <>, Dmitry Mezentsev <>, "Staff.RM OB" <>

Email template example:

Subject: Released 16Q4.x in 'QA Approved' and 'Confirm Stable' status

New versions of ERP and Retail are published in 'QA Approved' and 'Confirm Stable' maturity. Also ready to announce

QA Approved Maturity:
 ERP 3.0PR16Q4.2
 Retail 3.0RR16Q4
Confirm Stable Maturity
 ERP 3.0PR16Q3.5
 Retail 3.0RR16Q3.5

Email backports are available (normal and emergencies)

To: team.platform <>, Team ERP Engineering <>, Team Retail <>, Team StoreServer <>, Staff.RM OB <>, Sofware Factory <>

Email template

Subject: 17Q1.1 backport repositories available


17Q1 is published in 'QA Approved' status and 17Q1.1 repos are
available for backport.




IRC announce (normal and emergency if last)

Change the topic of the IRC channel #openbravo :

/msg chanserv op #openbravo <your nick>
/topic  Openbravo | Latest: 3.0PRyyQn | | POS support in forums:
/msg chanserv op #openbravo -<your nick>

Also in #openbravo-es :

/topic  Openbravo | Última versión: 3.0PRyyQn | | Soporte de POS en foros:

Enable int-promote (normal)

Enable job

Make POST_PUBLISH_ERP=true in ci To disable the 'SystemValidatorTest and check.module.consistency' for modules and retail job.

Check log update (normal)

Update the "Check log" script in jenkins and replace all the 99999 with the version of the erp published.

Update demo (normal)

1. Run the demo package job

Retrieve the resulting demo ip from the job. Note that both ERP and Retail execute this job

2. Check version in clone

 login http://<ip>/openbravo 
 Help -> about (check for version)

Send an email to, (get the ip from the mail sent by demo-pacakge job)

Demo machine for erp version yyQn.m is ready for testing
backend : http://<ip>/openbravo

3. If ok, run the demo publish job.

SERVERS demo-eu1 demo-us1
DEMO = erp

NOTE: This job does a system update + reboot of the demo machines (update server_update_sheet for date of demo system update)

4. check if the login works correctly in demo-eu1 and demo-us1

Confirmed Stable promotion (normal and emergencies)

When the MP was for 40 days in QA Approved it's needed to promote it to Confirmed Stable, execute in releaser machine:

Note: erp can only be promoted to Cs only after retail is published in QAA

example : if 16Q3.3 to CS make sure 16Q3.3 is already in QAA and ready for CS promotion

cd ~/releaser
./promote_cs 3.0PRyyQn 2>&1 | tee ../logs/promote_cs-3.0PRyyQn.log
INFO: Folders for 3.0PRyyQn in ~/repos, ~/output can be removed after promote to Confirmed stable maturity.

Update the status in the Release Notes page from QAA to CS

Update the Release Notes of the particular release, e.g: 3.0PR16Q4.3

Check update to QAA works

Modules reminder (emergency)

Note: Should be done only once when the version is first promoted to CS maturity.

cd ~/releaser
# Do a first check without send mails , check that no appear personal emails, only should appear the usual teams ones (erp engineering support one should not appear also)
./ cs 3.0PRyyQn emails-no
# real run sending the mails to teams
./ cs 3.0PRyyQn emails-yes 2>&1 | tee ../logs/modules-reminders-cs-3.0PRyyQn.log

After the first notification remind weekly to the teams till done.

Release Notes (normal and emergencies)

Announcement (normal and emergencies)

For announce this change search for previous release mail, and edit it accordingly:

Cancel the pending previous confirm stable emergencies (normal and emergencies)

For example if q3.x is promoted to cs, all the q2.x not published needs to be canceled.

In issues:

Example email for send to release management:

Subject: Canceled erp >= 15q2.7 and retail >= 15q2.6 releases

Hi all,

ERP and retail 15q3.x have been promoted to confirmed stable (CS), so all the pending (not yet published) 15q2.x releases of erp and retail are canceled.

As a consequence we have:
- retired the backports repositories
- rejected all the backports with that target version
- made this target version unavailable for new backports


Retrieved from ""

This page has been accessed 47,677 times. This page was last modified on 17 March 2017, at 05:56. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.