Nuxeo Core Developer Guide

Releasing

Updated: October 22, 2018 Page Information Edit on GitHub

Release Process

Here is an overview of the release tooling and process at Nuxeo.

Manual testing, code review, issue management and team collaboration are not mentioned in this document.

Release the Nuxeo Platform, including Main Addons and Nuxeo Packages

First check the source code is releasable:

Date-based releases are automatically performed every night, though they are not automatically published. Other kind of releases (FT, LTS) are preferably managed with IT-release-on-demand-build.

Release:

Everything is uploaded at http://community.nuxeo.com/static/staging/. Test the archives. If they are fine, move them out of the stagging repository.

All addons listed in org.nuxeo:nuxeo-addons-parent:pom are released at the same time.

All Nuxeo Packages listed in marketplace.ini are also released along with the platform.

Release Other Addons and Libraries

All other addons than those listed in https://github.com/nuxeo/addons/blob/master/pom.xml are individually released using IT-release-on-demand-addon.

Update the Documentation

Javadoc and Taglibs are updated by https://qa.nuxeo.org/jenkins/job/Misc/job/nuxeo-community-doc/.

Platform Explorer is upgraded and updated with an export from the released distribution, using the platform-explorer addon.

Scripts

Here are the main scripts used for the release processes:

Version Policy (Git Branching Model)

Here is the version policy applied at Nuxeo during development, maintenance and release.

There are a few variants in the release process (such as the onestep mode which prepares and performs the release in one unique step, without staging).

The Nuxeo Packages and the individual addons are released following the same model.

Main Branches

The main active branches are:

  • unstable development branch: master
  • validated development branches: x.y.z-SNAPSHOT
  • stable maintenance branches: x.y.z
  • specific development branches: fix-NXP-9999-someIssue, feature-NXP-9999-someFeature

Technical Steps to Release LTS 6.0 from Branch master (version 6.0-SNAPSHOT)

  1. Prepare the release
    1. checkout master
    2. from master: create and checkout maintenance branch 6.0
    3. on 6.0: replace versions in code: 6.0-SNAPSHOT => 6.0
    4. on 6.0: commit changes
    5. on 6.0: tag release-6.0
    6. on 6.0: replace versions in code: 6.0 => 6.0-HF01-SNAPSHOT
    7. on 6.0: commit changes
    8. checkout master
    9. on master: replace versions in code: 6.0-SNAPSHOT => 7.1-SNAPSHOT
    10. on master: commit changes
    11. checkout release-6.0
    12. on release-6.0: build and deploy to staging repositories
  2. Perform the release
    1. publish branches master and 6.0
    2. publish tag release-6.0
    3. checkout release-6.0
    4. on release-6.0: deploy to public repositories

Technical Steps to Release FT 7.1 from Branch master (version 7.1-SNAPSHOT)

  1. Prepare the release
    1. checkout master
    2. from master: create and checkout release branch 7.1
    3. on 7.1: replace versions in code: 7.1-SNAPSHOT => 7.1
    4. on 7.1: commit changes
    5. on 7.1: tag release-7.1
    6. checkout master
    7. on master: replace versions in code: 7.1-SNAPSHOT => 7.2-SNAPSHOT
    8. on master: commit changes
    9. delete branch 7.1
    10. checkout release-7.1
    11. on release-7.1: build and deploy to staging repositories
  2. Perform the release
    1. publish branch master
    2. publish tag release-7.1
    3. checkout release-7.1
    4. on release-7.1: deploy to public repositories

Maintenance and Development

Technical steps to fix NXP-9999 on current master development branch (version 7.3-SNAPSHOT) with a backport to 6.0 maintenance branch (version 6.0-HF15-SNAPSHOT):

  1. Prepare the fix

    1. checkout master
    2. from master: create and checkout maintenance branch fix-NXP-9999-someFix
    3. on fix-NXP-9999-someFix: fix the issue
    4. on fix-NXP-9999-someFix: commit changes
    5. publish branch fix-NXP-9999-someFix
  2. Backport the fix
    1. checkout 6.0
    2. from 6.0: create and checkout maintenance branch fix-NXP-9999-6.0-someFix
    3. on fix-NXP-9999-6.0-someFix: cherry pick the changes from fix-NXP-9999-someFix
    4. on fix-NXP-9999-6.0-someFix: commit changes
    5. publish branch fix-NXP-9999-6.0-someFix
  3. Test and Publish the fix That is done by the Continuous Integration, see Isolated Testing ("Test&Push" jobs). Depending on the options, the process looks like:

    1. checkout fix-NXP-9999-someFix
    2. on fix-NXP-9999-someFix: rebase on master (parent branch)
    3. on fix-NXP-9999-someFix: build and test
    4. checkout master
    5. on master: merge fix-NXP-9999-someFix
    6. publish branch master
  4. Test and Publish the backport
    1. Repeat step 3 with branch fix-NXP-9999-6.0-someFix and parent branch 6.0

Feature development follows the same process (without backport of course): step 1, step 3.

Maintenance and development branches are preferably updated against their parent branch with a rebase rather than a merge.

2 months ago manonlumeau NXDOC-1650 fix about integrating changes, add mention on multiple attempts
2 years ago Ronan Daniellou 13 | pdates "IT-release-on-demand-addon" target UR
3 years ago Solen Guitter 12 | NXDOC-658: Marketplace packages are now called Nuxeo Packages
3 years ago Julien Carsique 11
5 years ago Julien Carsique 10
6 years ago Julien Carsique 9
6 years ago Julien Carsique 7
6 years ago Julien Carsique 8 | Migrated to Confluence 4.0
6 years ago Julien Carsique 6 | NXDOC-125 - update release doc
6 years ago Anahide Tchertchian 5
7 years ago Julien Carsique 4
7 years ago Julien Carsique 3
7 years ago Julien Carsique 2
7 years ago Julien Carsique 1
History: Created by Julien Carsique

We'd love to hear your thoughts!

All fields required