Page History

References to ASF official pages

...

https://www.apache.org/dev/release-signing.html

http://www.apache.org/dev/mirrors (deprecated, historically interesting)

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 https://nightlies.apache.org/ofbiz/stable/rat-output.html. For that you can use
   https://nightlies.apache.org/ofbiz/stable/rat-output.html for the current stable version
   https://nightlies.apache.org/ofbiz/next/rat-output.html for the current next version, ie the version never released yet
   You can include files that don't need license in https://github.com/apache/ofbiz-tools/blob/master/rat-excludes.txt
3. Check no open blocker Jira issues are still pending:

   Jira
   server ASF JIRA jqlQuery filter=12344205 serverId 5aa69414-a9e9-3523-82ec-879b028fb15b

4. If you load a new gradle wrapper version, update shasum signature on $OFBIZ_HOME/gradle/init-gradle-wrapper.sh

   Code Block
   language bash title SHASUM GRADLE
   # checksum to verify the downloaded file SHASUM_GRADLE_WRAPPER_FILES="1d23286bcb9e7d3debff18c1b892b9dbb9a4ec6c gradle/wrapper/gradle-wrapper.jar f9c2ad227ef1fe774cb0e141abfc431b05fc9fd4 gradle/wrapper/gradle-wrapper.properties b4a6a7e1dca81a692a775193fada937e035265f3 gradlew"

   
   

5. 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 named: release<YY.MM.NN>
   1. For example: release18.12.02
   2. Create the release tag on all the relevant repositories such as ofbiz-framework and ofbiz-plugins 
2. Export/extract
3. create a release tag
4. export the release branch in a local folder named apache-ofbiz-<YY.MM.NN>
5. add a file named revision.txt containing the revision number of the exported codebase
6. Modify the following files in the main folder:
   1. 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);
   2. put the release version number in the VERSION file.
      
7. Remove the Gradle wrapper bin files
8. Compress the exported folder as apachezip the exported folder as apache-ofbiz-<YY.MM.NN>.zip
9. create Create an OpenPGP Compatible ASCII Armored Detached Signature named apachenamed apache-ofbiz-<YY.MM.NN>.zip.asc
10. create an MD5 Checksum named apache-ofbiz-<YY.MM.NN>.zip.md5
11. create an Create an SHA512 Checksum named apache-ofbiz-<YY.MM.NN>.zip.shasha512
12. commit Commit the 4 3 release files to to https://dist.apache.org/repos/dist/dev/ofbiz/
13. Update the doap_OFBiz.rdf file

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 md5 checksum of release zip file against the .md5 filecheck 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):http https://svngithub.com/apache.org/reposofbiz-tools/asfblob/ofbizfdbae25fa8e11355742b403f72cb80f4a0c32262/tools/verify-ofbiz-release.sh

Publishing the Release

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

...

1. move the release files from https://dist.apache.org/repos/dist/dev/ofbiz/ to https://dist.apache.org/repos/dist/release/ofbiz/

Updating related files

1. /ofbiz

...

1. /

...

http://ofbiz.apache.org/source-repositories.html

https://svn.apache.org/repos/asf/ofbiz/trunk/tools/demo-backup/README

https://svn.apache.org/repos/asf/ofbiz/site/doap_OFBiz.rdf

Please complete the list if necessary...

Announcing the Release

These steps must can be done after at least 24 hours 15 minutes after the release has been published (time required for the propagation transmission of the release files in to the mirrors networkCDN):

1. Add a news item to the main page of the OFBiz website: http://ofbiz.apache.org/index.html
2. Add the information about the release to the OFBiz download page: http://ofbiz.apache.org/download.html
3. Create an html page with the release notes (generated by Jira)
   
   1. In Jira, mark the version as "released" and create a new version for the next release
4. If necessary, update the security page on siote
5. Add the information about the release to the release history page: http://www.apache.org/dist/ofbiz/
6. Send an announcement to the user, dev and announce@apache.org lists; if the release contains vulnerability fixes send also to security@apache.org

7. Update related files

   http://ofbiz.apache.org/download.html
   http://ofbiz.apache.org/source-repositories.html
   http://ofbiz.apache.org/security.html
   https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
   https://github.com/apache/ofbiz-site/blob/master/doap_OFBiz.rdf
   Please complete the list if necessary...

8. Update the release informations on other sites: OFBiz on other sites
9. If it's an EOL release announce using one of the files at https://svn.apache.org/repos/private/pmc/ofbiz/security/EOL-Drafts

Creating a new release branch

From time to time, every 1-2 years, the OFBiz community create a release branch from the master branch in order to start the stabilization process.

This paragraph describes the steps involved in the creation of the release branch:

1. Create a new branch named release<YY.MM>
   1. For example: release18.12 is the name of the release branch created in December, 2018
2. Edit the VERSION file in the OFBiz home folder to contain the same <YY.MM> of the release branch
3. In Jira, rename the version "Upcoming Branch" into "<YY.MM.01>" (i.e. the name of the first release of the new branch)
4. In Jira, create a new version named "Upcoming Branch" and move to it all the open tasks that were assigned to "Upcoming Branch" and are not planned to be resolved in <YY.MM.01>
5. Check Creating a new branch in BuildBot and update the BuildBot.md file
   
6. Update the demos documentation, the next-manual and next patches files under demo-backup
   
7. In the new main README.adoc change from trunk to  release<YY.MM> where it fits
8. Update the GitHub workflows files changing from trunk to  release<YY.MM> where it fits.
   Notably modify .github/workflows/codeql-analysis.yml, <<branches: "[ trunk ]">> to <<branches: "[ release<YY.MM> ]">
9. Update the developers page on site: https://ofbiz.apache.org/developers.html
10. Copy the CONTRIBUTING.adoc file from the current stable to the new branch

Branch EOL (End Of Life)

In order to help our users to decide about what to do with branches EOL we decide x months ago to send an announcement. When the time is passed we send a confirmation announcement about the EOL.

For now we have only sent a direct announcement (no pre-announcement) for 17.12.09 release. A draft for the 18.12 branch exists. These are only accessible to PMC members.