Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

Overview

  • No cross-project SNAPSHOT dependencies
  • Teams to version and release their own artifacts on their own schedule
  • Version numbers should conform to the Semantic Versioning 2.0.0 Specification
  • ONAP community "simultaneous release" is composed of a collection of artifact versions defined in a "version manifest" in source control
  • ONAP Version Manifest Maven Plugin to check against outdated dependencies vs. the manifest
    • Teams to version bump their dependencies per their convenience

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

Rationale

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

Roll-out Schedule

  • Due to potential cascading dependencies, and the fact that some teams may not be ready to formally release artifacts before M4 Code Freeze, we expect some teams to need more time to be able to remove all their SNAPSHOT dependencies.
  • Ideally, by RC0 all project teams should have already formally released at least one version of their artifacts.  So by this time we should be able to start enforcing the no SNAPSHOTs requirement.

Java (Maven) Artifacts Release Process

  • Ensure that your artifacts inherit from O-Parent (oparent)
    • If not possible, please maintain your own implementations of the various configurations and checks provided by oparent
  • Remove all external SNAPSHOT dependencies
    • External = cross-project (including oparent) or 3rd party
    • Check version manifest at https://git.onap.org/integration/tree/version-manifest/src/main/resources for the right version to use for your cross-project dependencies

      • The Integration team is providing a Maven plugin to warn you of outdated references: ONAP Version Manifest Maven Plugin.  To use it, run the following command:

        mvn org.onap.integration:version-manifest:version-check
    • 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
  • Set up -release-version jobs (staging 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
  • Ensure that the staging jobs above have completed and generated candidate artifacts
  • Perform any necessary testing against the candidate artifacts
  • Email helpdesk@onap.org to select a candidate as formal release artifact
  • Update the declared version numbers for your respective artifacts in the java version manifest: https://git.onap.org/integration/tree/version-manifest/src/main/resources/java-manifest.csv
  • Update the CHANGELOG to describe the changes that were part of this release
    • TBD: CHANGELOG structure and update process is being developed by the Documentation project
  • Bump your own version numbers for ongoing development
    • SNAPSHOT versions in pom.xml
    • Staging/Release version in version.properties

Docker Images Release Process

Prepare your docker images.  Here is the high level flow relating the various Java artifact versions to Docker tags:

  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.

Docker image release process:

Standardized Docker Tagging

TODO: Michael to send out onap-discuss meet for 2nd next PTL meet - based on brainstorming the docker versioning in terms of the CD process (Marco, Gildas, Gary, Michael)

OOM-500 - Getting issue details... STATUS

References

  • No labels