Page History

...

1. There is a known issue in the Sonatype Nexus staging feature such that it only indexes the FIRST version of a zip or tarball that is created - not the most recent.  For example, suppose that the current version is 0.2.3-SNAPSHOT, and thus the version built if you do a "release" build (either due to daily builds or due to posting the comment "please release") is 0.2.3.  If you request version 0.2.3 of an installation zip stored in staging, it will not get you the NEWEST 0.2.3, but rather will get the OLDEST 0.2.3.  Because of  To work around this issue, you always want to roll versions right before you create a release version, not immediately AFTER as you normally would expect, we add the suffix "-STAGING" to the release version during development, and only remove it when creating a release build.  This guarantees that the release version will be consistent, since we will create only one release version.
2. The CCSDK parent poms contain properties that specify the current version of each CCSDK sli repository.  Unfortunately, this means that if any CCSDK repository has to be released, the CCSDK parent pom and all 4 CCSDK sli repositories need to be released - meaning their versions also have to be rolled.

The following is the procedure that must be followed to release new versions of CCSDK artifacts:

1. Create release version of ccsdk/parent:
   1. Update  version.properties to remove -STAGING tag and to update ccsdk versions within parent poms to the release version.  Submit change and, after merge build completes, do a release build by posting "please release" as comment.
   2. Roll  to next snapshot version.   Restore the -STAGING tag to version.properties, and update ccsdk versions within parent poms to the next snapshot version.
2. Mail helpdesk@onap.org to create a ticket requesting release of new CCSDK parent poms.  In ticket, be sure to include link to Jenkins release build triggered by step 1a. WAIT for LF IT to create release version of parent poms before proceeding to next step
3. Create release version of ccsdk/sli/core:
   1. Update version.properties to remove -STAGING tag and update
   properties containing current version to use
   1. pom.xmls to use released version of parent poms just created.  Submit change and, after merge build completes, do a release build by posting "please release" as comment.
   2. Roll to next snapshot version.   Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
   Roll
4. Mail helpdesk@onap.org to create a ticket requesting release of new ccsdk/sli repos (sli/core.  In ticket, be sure to include link to Jenkins release build triggered by step 3a.  WAIT for LF IT to create release version  before proceeding to next step.
5.  Create release versions of ccsdk/sli/adaptors, ccsdk/sli/northbound, ccsdk/sli/plugins, distribution) to next snapshot and update to use new snapshot and ccsdk/features.  For each repo:
   1. Update pom.xmls to use newly created release version of parent pom and remove -STAGING tag from version.properties.  Do a release build.
    Note: be sure to do the repos in the order listed.  core must be done first; then adaptors,northbound and plugins ; and lastly distribution.
6. Create new CCSDK docker containers
7. Rerun CSIT to make sure it still passes
8. Update parent poms to update properties containing version to the next version
   Note: at this point, builds of sli/adaptors, sli/northbound, sli/plugins and distribution will break, because we have not yet released sli/core. 
9. 1. Roll to next snapshot version.   Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
10. Mail helpdesk@onap.org to create a ticket requesting release of new ccsdk/sli/adaptors, ccsdk/sli/northbound, ccsdk/sli/plugins and ccsdk/features.  In ticket, be sure to include link to Jenkins release builds triggered by step 5a.  WAIT for LF IT to create release versions  before proceeding to next step.
11. Create release version of ccsdk/apps (micro services):
    
    1. Update pom.xmls to use newly created release version of parent pom and remove -STAGING tag from version.properties.  Do a release build.
    2. Roll to next snapshot version.   Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version
    Create staging version of ccsdk/parent by posting comment "please release" to commit for previous step
    1. .
12. Mail helpdesk@onap.org to create a ticket requesting to release new CCSDK parent poms. In release of new ccsdk/apps.  In ticket, be sure to include link to the Jenkins release build triggered by previous step .
    NOTE: do NOT continue 7a.  In this case, it is NOT necessary to wait before proceeding to next step until Linux Foundation has released parent poms.
13. Create release version of ccsdk/distribution (docker containers):
    1. Update pom.xmls to use newly created release
    Update ccsdk/sli repos to use released
    1. version of parent pom and remove -STAGING tag from version.
14. Create new staging versions of ccsdk sli repos (core, adaptors, northbound, plugins)
15. Create new CCSDK docker containers
16. 1. properties.  Do a release build.
    2. Roll to next snapshot version.   Restore the -STAGING tag to version.properties, and update versions of parent poms to the next snapshot version.
    Rerun CSIT to make sure it still passes
17. Mail helpdesk@onap.org to create a ticket requesting to release CCSDK sli repos (core, adaptors, northbound, plugins).  In release of new ccsdk/distribution.  In ticket, be sure to include link to reference Jenkins release builds trigger build triggered by step 107a.