Rationale

Details on the history and discussions that led to this process can be found at Release Versioning Strategy.

Benefits

• No unexpected build failures due to upstream SNAPSHOT changes
• No need for cross-project consolidated “mega builds” to check dependency issues
• Avoids issues with trying to synchronize artifact version numbers across projects
• Improved dev and build cycle time

Process Overview

• No cross-project SNAPSHOT dependencies
• Teams to version and release on own schedule
• Source control central artifact version manifest
  • Teams to declare the “correct version” for cross-project use
  • Manifests located in integration repo: https://git.onap.org/integration/tree/versions/
  • TSC to approve version manifest for simultaneous release, e.g. Amsterdam
• Maven plugin to warn against outdated dependencies vs. the manifest

Java (Maven) Artifacts Release Process

• Ensure that your artifacts inherit from oparent
  • If not possible, please maintain your own implementations of the various configurations and checks provided by oparent
• Set up -release-version jobs to deploy candidate artifacts to Staging
  • Generates candidate “autorelease-xxxx” directories in Nexus
  • Ensure that your version.properties file has the right version number defined for the intended release
• Perform any necessary testing against the candidate artifacts
• Remove all external SNAPSHOT dependencies
  • External = cross-project (including oparent) or 3rd party
  • Check version manifest at https://git.onap.org/integration/tree/versions/java-manifest.csv for the right version to use for your cross-project dependencies
  • If your upstream cross-project dependencies haven't entered their artifacts in the manifest above, please contact the respective project team to get them to version/release their artifacts and add their entries to the manifest
  • Remove ecomp-staging Nexus repo from your local ~/.m2/settings.xml repositories list; all release-versioned artifact dependencies should be fulfilled from the ecomp-releases repo only going forward
• Email helpdesk@onap.org to select a candidate as formal release artifact
  • Specify the specific Jenkins build job that generated the selected candidate build, e.g. https://jenkins.onap.org/view/oparent/job/oparent-master-release-version-java-daily/16/
  • LF will GPG sign and release the artifacts to Releases repo
  • LF will place a GPG signed tag on the specific commit in Gerrit repo
• Update the declared version numbers for your respective artifacts in the manifest located in the integration repo: https://git.onap.org/integration/tree/versions/java-manifest.csv
• Bump your own version numbers for ongoing development
  • SNAPSHOT versions in pom.xml
  • Staging/Release version in version.properties

Docker Images (work in process)

Proposed Java/Docker versioning flow:

1. Produce SNAPSHOT Java artifact.  Test this in a SNAPSHOT docker image.
2. Produce staging (release candidate) Java artifact.  Test this in a SNAPSHOT docker image.
3. Produce release Java artifact by picking one of the candidates from staging. 
4. Produce STAGING docker image using the release Java artifact.  Use this in E2E test flows.
5. Produce RELEASE docker image by picking one of the candidate STAGING docker images.

References

• https://lists.onap.org/pipermail/onap-discuss/2017-August/003454.html
• https://lists.onap.org/pipermail/onap-discuss/2017-August/003967.html