This document describes the different phases of the release engineering process leading up to the actual build and publication of a openbravo retail release.
Check issues target (normal and emergencies)
- Check in issues that all the issues targeted for the current RRyyQn are close.
- Check that it is not needed to wait for a specific commit.
Remove permissions to repo (emergencies)
Remove push permissions to backport repo.
Update the main repo and branch out the current release (normal)
- Update the retail/main/<retail_repos> to include changesets from erp/pmods/<retail_repos>
- Create clone of main to retail/backport/<current_release>
log in to code.openbravo.com as apache user execute ./make_retail_backport_repo.sh 3.0RRyyQn
Email retail pmods repos are open for next mp (normal)
Send an email to release management list
pmods retail repo are open for next release. Any issue in current release must have separate issue with type "backport" and target_version 3.0RRyyQn, and the changesets must get in to backport repos https://code.openbravo.com/retail/backports/3.0RRyyQn/ The dates for RRyyQn are the usual ones .  http://wiki.openbravo.com/wiki/Release_Policy#ERP_release
Check for the version of the modules (normal & emergency)
Modules that needs to be published are:
Emergencies: only with new commits. To check this open the backport repo and the ones that don't have last commit with our hg user (RM packaging bot).
The ones that have to be published will have the P in the config file.
Check org.openbravo.agingbalance module version (normal)
org.openbravo.agingbalance is external module added to dependency list of retail.pack.
Send mail to Álvaro Ferraz,Víctor Martínez, David Miguélez to confirm on the module version and promote to QA and the tag of the version exist in mercurial repo.
Create config file (normal and emergencies)
Use screen for release process
- Create config_3.0RRyyQn inside /home/packager/releaser/retail
Things to be taken care on creating the config file
- T Tag the module, for all the modules that are managed by rm in the release
- TP Tag and publish the module, when the repo has changes from past release
- N Just update the module dependency, for the external modules
- Numbering increment, only to modules that are going to be published(the ones with changes):
- by 200 for main release (Note*)
- IMPORTANT: in normal releases update ALL the modules, needed to avoid to major version to share one module and when one relase move to qaa, if the package is already in cs is not moved back to qaa.
- by 10 for emergency release, if case of more than 10 emergencies, raise topic to team.
- by 1 for each repackage
- by 200 for main release (Note*)
- Note* : the increment should be done taking as base the first previous release package, for example Q1 -> 500, Q1.8 -> 580, then for Q2 should be 700
Note : For emergencies, update the version for the modules which has new changeset and need to be published.
T 1.3.2120 org.openbravo.retail.discounts TP 1.2.2130 org.openbravo.retail.posterminal T 1.0.1410 org.openbravo.retail.config T 1.0.1010 org.openbravo.mobile.core T 1.0.320 org.openbravo.retail.returns T 1.0.120 org.openbravo.retail.sampledata T 1.0.1510 org.openbravo.retail.poshwmanager TP 1.8.330 org.openbravo.retail.pack N 3.1.31 org.openbravo.agingbalance N 1.0.1 org.openbravo.financial.cashflowforecast
Run the package
Note : Make sure the retail is packaged when erp is packaged, so the retail has the latest erp verion (for normal release only)
cd /home/packager/releaser/retail ./package 3.0RRyyQn 2>&1 | tee ../../logs/package-3.0RRyyQn.log
./package 3.0RRyyQn build-qa 2>&1 | tee ../../logs/package-3.0RRyyQn.log
Update qa machine (normal)
Do system update off all
/etc/init.d/tomcat stop apt-get update apt-get dist-upgrade apt-get autoclean apt-get --purge autoremove reboot
Since the update of the erp is quite dificult we do it instead of qa, here is the doc , check the end part: udpate.
Release Notes (normal and emergencies)
- Create the wiki document Retail:Release_Notes/RRyyQnX and copy the structure of the template.
- Write the estimate publish date
Complete list of fixed issues in the RR (normal)
TODO: create changelog script to get this from backport repo !!
Complete list of fixed issues in the RR (emergency)
- login to issues as openbravo user and execute
$ /rt/changelog_script/get_backport_issues.sh RRyyQn.x example : $ /rt/changelog_script/get_backport_issues.sh RR16Q2.3
Optionally can be checked with roadmap page to ensure that is correct: https://issues.openbravo.com/roadmap_page.php
Update API changes wiki (normal and emergencies)
Update the API changes list, as follows:
- Rename PI to RRyyQn, e.g. RR14Q2.
- Create a new empty section for PI.
Email of release notes (normal)
Send an email to team leaders to write the "Whats New" and "Extension" section with meaningful messages.
Recipients: Antonio, Dmitry, staff.rm
Email of packaging (normal and emergencies)
Send an email to release management list and to staff qa.
Subject: RRyyQnXX-testing Version of Retail Pack in CR : ... [ include the versions of all retail modules can be take from config file ] ... Release notes: http://wiki.openbravo.com/wiki/Release_Notes/3.0RRyyQn Instance for QA: http://XX
Edit config file (normal and emergencies)
Check new commits
cd /home/packager/output/3.0RRyyQn/repos for repo in $(ls -1) ; do hg in -R $repo ; done
For the modules with new changesets updfate the version and TP string in file /home/packager/retail/config_3.0RRyyQn
T (tag the module) and P (publish/upload to CR).
- Increase the module version by 1 for the modules that has new transplants
- Add 'P' letter to the modules for which there is changes
- Remove 'P' letter from modules which don't have changes
- For the pack: add the 'P' and also increase the version in 1
Package (normal and emergencies)
cd /home/packager/releaser/retail ./package 3.0RRyyQn 2>&1 | tee ../../logs/package-3.0RRyyQn.v2.log
Note : If QA request to rebuild the test machine pass 'build-qa' as parameter to package command ./package 3.0RRyyQn build-qa
After that can be followed the normal process to send email and create qa machine.
Email of the package (normal and emergencies)
Sent email of the repackage done, and include the new issues added.
Remove permissions to repo (only normal)
Remove push permissions to repo in code.
Publish artifacts (normal and emergencies)
- push the tag to repositories.
cd /home/packager/releaser/retail ./publish 3.0RRyyQn 2>&1 | tee ../../logs/publish_3.0RRyyQn.log
Merge to main (normal and emergencies)
After run the previous script, if we are releasing a emergency update run
cd /home/packager/releaser/retail ./merge-retail-to-main.sh 3.0RRyyQn 2>&1 | tee ../../logs/merge-retail-to-main_3.0RRyyQn.log
Merge main back to pi (normal and emergencies)
Connect to code and using the user that is owner of repos execute:
./retail-merge-main-pi.sh 3.0RRyyQn 2>&1 | tee retail-merge-main-pi_3.0RRyyQn.log
Note: currently is under development, needed manually to ensure to pass the module and dependencies versions from main to pi.
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.
Create new repo in code (normal & emergencies)
Close the current used backports repos and create new ones for the next version.
Example: if we publish Q3 create repo for Q3.1, if we publish Q3.1 create Q3.2
- login as apache user and execute
- Check the old release folder in retail/backports is removed
Push the automation tag (normal & emergency)
automation/pi-mobile is branched to backports path for all release of retail.
- For normal releases the pi-mobile need to tagged (mandatory)
- For emergeny if any new changesets in retail/backports/3.0RRyyQn.x/pi-mobile and retag the existing 3.0RRyyQn.
- Example : Current release is 16Q2.2 and there are new changesets in retail/backports/3.0RR16Q2.1/pi-mobile, it is must to retag 3.0RR16Q2 to include the new changesets.
cd releaser/retail ./merge-pi-mobile-tags.sh 3.0RRyyQn 2>&1 | tee merge-pi-mobile-tags-3.0RRyyQn.log
Mantis (normal and emergencies)
Go to https://issues.openbravo.com , and select manage -> projects -> retail moduels.
In the versions mark the current RRyyQn version as released.
Create a new target versions of the type of the just published. Idea is that should be two actives branches in each thread. For example should be 2 normal released available, 2 target versions of q1.x and 2 target versions of q3.x.
Release notes (normal and emergencies)
- If was needed to do any transplant, remember to recreate the fixed issues section in the release notes
- Add in release notes the new MP released.
- Clean up the MP release note document http://wiki.openbravo.com/wiki/Retail:Release_Notes/3.0RRyyQn
- Remove the WorkInProgress banner
- Remove the "Great feature" texts
- Correct the 'release date and version'
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.
Announcements (normal and emergencies)
- Send the generated mail to the on-update-announce and openbravo development mailing lists in two different emails.
The template of the mail should be something similar to this:
Subject: Openbravo for Retail RRyyQn is available Openbravo for Retail RRyyQn is available in the QA Approved status  These are the new features added to this release * Feature  * Feature  During this release following modules were created / updated: * Modules  * Modules  Check the release notes for complete list: http://wiki.openbravo.com/wiki/Retail:Release_Notes/RRyyQn Copyright 2008-2014 Openbravo, S.L.U.  http://wiki.openbravo.com/wiki/Modules_Management#Maturity_Status  http://wiki.openbravo.com/wiki/Retail:feature1
Update demo (normal and emergency if last)
Run the retail demo package job .
Send email to retail team to check the demo.
After they ok, run the demo publish job . NOTE: This job does a system update + reboot of the demo machines
Clean up qa instances (normal and emergencies)
Delete the instances created for qa testing.
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,
cd /home/packager/releaser/retail ./promote_cs 3.0RRyyQn 2>&1 | tee ../../logs/promote_cs-3.0RRyyQn.log
NOTE: Do Test the retail publish, start a ec2 machine with erp CS and install retail module in CS
Release Notes (normal and emergencies)
- Set Maturity level column to CS in the the general Retail Release Notes page.
- Update the Release Notes page of that release and remove the message about the module being available in QA Approved.
Announcement (normal and emergencies)
For announce this change should be sent a mail to openbravo-development and on-update-announce with this template:
Subject: Openbravo for Retail RRyyQn - Confirmed Stable Openbravo for Retail RRyyQn has reached the "Confirmed Stable" maturity level. Read more about maturity levels  and configure  your Openbravo instance according to your needs. Openbravo for Retail RRyyQn release notes: http://wiki.openbravo.com/wiki/Retail:Release_Notes/RRyyQn Copyright 2008-2014 Openbravo, S.L.U.  http://wiki.openbravo.com/wiki/Modules_Management#Maturity_Status  http://wiki.openbravo.com/wiki/Modules_Management#Advanced_settings
Cancel the pending previous confirm stable emergencies (normal and emergencies)
This is common for erp and retail: Link to this part in the erp release process