| Table of Contents |
|---|
...
- 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
- Teams to declare and update the “correct version” for cross-project use and for inclusion in simultaneous release
- Manifests located in integration repo: https://git.onap.org/integration/tree/version-manifest/src/main/resources
- TSC to approve version manifest for simultaneous release, e.g. Amsterdam
- ONAP Version Manifest Maven Plugin (Decommissioned) to check against outdated dependencies vs. the manifest
- Teams to version bump their dependencies per their convenience
...
- 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 (Decommissioned). To use it, run the following command:
Code Block 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 gerrit-releasemaven-version jobs stage (staging jobsjob from global-jjb) to deploy candidate artifacts to Staging in Nexus2
- 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@onapCreate a service request to LF Releng (support.linuxfoundation.org) to select request a candidate as formal release artifactrelease of the staging candidate
- Specify the specific Jenkins build job that generated the selected candidate build, e.g. https://jenkins.onap.org/view/oparentaai-aai-common/job/oparentaai-masteraai-releasecommon-versionmaven-javastage-dailymaster/1623/
- 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 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
- The gerrit-maven-stage job provides a patch that the teams can apply for their convenience. e.g. https://logs.onap.org/production/vex-yul-ecomp-jenkins-1/aai-aai-common-maven-stage-master/23/patches/
Docker Images Release Process
...
Docker image release process:
- Set up gerrit-maven-docker-stage (docker staging jobs job from global-jjb) to produce the STAGING docker images.
- Ensure that the docker staging jobs 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 artifactCreate a service request to LF Releng (support.linuxfoundation.org) to request a release of the staging candidate
- Specify the specific Jenkins build job that generated the selected candidate build, e.g. https://jenkins.onap.org/view/oparentclamp/job/oparentclamp-mastermaven-releasedocker-versionstage-java-dailymaster/1652/
- LF to re-tag the selected STAGING docker image with a RELEASE version tag
- Update the declared version number for your docker image in the docker version manifest: https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-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
- Staging/Release version in version.properties
...
What do we
...
need standardized Docker format for?
As Docker Snapshot is a cumulative repository, given a version, a keyword and the name of an image, the there is need is for a systematic method to sort images chronologically images based on Nexus version field.
This will help community to community in providing provide an automated deployment using tag sets on a standard format.
Proposal
The proposed docker tag format to align across all the teams is the following:
...
X.Y.Z follows the Semantic VersionningVersioning
KEYWORD: SNAPSHOT or STAGING
Example
| 1.1.2-SNAPSHOT-20181231T234559Z |
|---|
See similar examples of the current tag structure by browsing the links below. Unfortunaltly Unfortunately there is no consistency among projects. Note that these examples have additional keyword (such as SNAPSHOT) that are currently not deemed necessary.
...
snapshot
https://nexus.onap.org/#view-repositories;snapshots~browsestorage
name-1.2.0-timestamp
proposal: use symantic semantic version v1.1.1 - is released (no latest tag) - unchanged
1.1.2-snapshot is the next under test
1.1.2-timestamp (here we need LF to pick up the format)
proposal: Timestamp-yyyy-mm-dd-Thh-mm-ssZ
or version-yyyymmddThhmmssZ (no :)
1.1.2-20181231T234559Z
fill out and merge Gildas slides
to
https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Independent+Versioning+and+Release+Process#IndependentVersioningandReleaseProcess-StandardizedDockerTagging
send mail to discuss and meeting 2nd monday
...
observation
- teams only have visibility on changes marked in the manifest file - not "in-development" merges
- we will likely need to group commits under test (lack of resources) - developers will need to triage together a test set that marked (n) commits in a timeframe as breaking CD
-