Overview
- No cross-project SNAPSHOT dependencies
- Teams to version and release their own artifacts on their own schedule
- ONAP community "simultaneous release" is composed of a collection of artifact versions defined in a "version manifest" in source control
- Teams to declare and update the “correct version” for cross-project use and for inclusion in simultaneous release
- Manifest 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 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.
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:
- Produce SNAPSHOT Java artifact. Test this in a SNAPSHOT docker image.
- Produce staging (release candidate) Java artifact. Test this in a SNAPSHOT docker image.
- Produce release Java artifact by picking one of the candidates from staging.
- Produce STAGING docker image using the release Java artifact. Use this in E2E test flows.
- Produce RELEASE docker image by picking one of the candidate STAGING docker images.