Access to add and change pages is restricted. See:

Skip to end of metadata
Go to start of metadata

References to ASF official pages

Things to check before a release (these tasks can be delegated by the RM (Release Manager))

  1. Check if there are any bugfixes in trunk which need to be backported to the release branch (see How should committers handle backporting?).
  2. Check all files are correctly licensed at You can include files that don't need license in
  3. Check that no open blocker Jira issues are still pending:

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

  4. Check if the gradle wrapper version use by this release is present on bintray If not the case follow Load new gradle wrapper version on bintray
  5. If you load a new gradle wrapper version, update shasum signature on $OFBIZ_HOME/gradle/

    # checksum to verify the downloaded file
    SHASUM_GRADLE_WRAPPER_FILES="1d23286bcb9e7d3debff18c1b892b9dbb9a4ec6c  gradle/wrapper/gradle-wrapper.jar
    f9c2ad227ef1fe774cb0e141abfc431b05fc9fd4  gradle/wrapper/
    b4a6a7e1dca81a692a775193fada937e035265f3  gradlew"
  6. Check if there are deprecated services to remove. That's easily done by looking for "has been deprecated and replaced by" in console.log.

Release Workflow

The workflow for a new release has four phases: preparing a candidate release, voting, publishing the release, announcing the release.

Preparing a Candidate Release

  1. create a release tag
  2. export the release branch in a folder named apache-ofbiz-<YY.MM.NN>
  3. Modify some of the files in the folder:
    1. remove the Gradle wrapper bin files
    2. edit the LICENSE file: if it is a framework+plugins release then simply remove the LICENSE file under plugins; if it is a framework only release then edit the LICENSE file to remove the references to plugins; if it is a plugin release that add NOTICE and check the validity of the LICENSE file (or add one if missing)
  4. compress the exported folder as apache-ofbiz-<YY.MM.NN>.zip
  5. create an OpenPGP Compatible ASCII Armored Detached Signature named apache-ofbiz-<YY.MM.NN>.zip.asc
  6. create an SHA512 Checksum named apache-ofbiz-<YY.MM.NN>.zip.sha512
  7. commit the 3 release files to

Voting on a release

The vote takes place in the developers mailing list. People who want to vote should do the following checks:

  1. check sha checksum of release zip file against the .sha file
  2. check signature of release zip file against the .asc file
  3. unzip the release file, build and run integration tests. The build should be successful.

The checksum and signature verification can also be done by the following convenience script (bash):

Publishing the Release

After a successful vote, the Candidate Release becomes an official Release and can be published:

  1. move the release files from to

Updating related files

Please complete the list if necessary...

Announcing the Release

These steps can be done after at least 24 hours after the release has been published (time required for the propagation of the release files in the mirrors network):

  1. Add a news item to the main page of the OFBiz website:
  2. Add the information about the release to the OFBiz download page:
  3. Create an html page with the release notes
  4. If necessary, update the security page
  5. Add the information about the release to the release history page:
  6. Send an announcement to the user, dev and lists; if the release contains vulnerability fixes send also to
  7. Update the release informations on other sites: OFBiz on other sites
  • No labels

1 Comment

  1. Thanks Jacopo Cappellatofor handling the new LICENCE file in plugins current "issue"