Difference between revisions of "Archived-Hc2vpp/BranchCutting"

Revision as of 09:53, 4 February 2019

Jenkins

In jjb/hc2vpp/hc2vpp-csit.yaml and jjb/hc2vpp/hc2vpp.yaml add a new ‘stream’ for your new YYMM (example: for stable/1901):

- '1901':
            branch: 'stable/1901’'
            repo-stream-part: 'stable.1901'

(example: https://gerrit.fd.io/r/#/c/16919/).

Cut branch

Create a new branch stable/YYMM (example: stable/1901) in the gerrit web UI against the point on master you wish to be cutting the branch (usually HEAD at the time your cutting).

https://gerrit.fd.io/r/#/admin/projects/hc2vpp,branches

Update stable/YYMM branch

On stable/YYMM (example: stable/1901) prepare a commit which updates the .gitreview to reflect the correct branch.

Example: https://gerrit.fd.io/r/#/c/17047/

Also update <project-branch> in the release notes

Example: https://gerrit.fd.io/r/#/c/17048/

and RPM/DEB release to RC1~$BUILD_NUMBER.

Example: https://gerrit.fd.io/r/#/c/17050/

Update the maven versions of hc2vpp artifacts to x.YY.MM-RC1 (example: 1.19.01-RC1).

Remember to also update versions in package scripts (files: prepare.sh, release, rpmbuild.sh and honeycomb.spec). And don't forget to update csit-test-branch (rls1901 in example).

Example: https://gerrit.fd.io/r/#/c/17052/

Verify correct artifact versions

After integration job for version bump patch is finished, check if

• RPMs with the correct versions were deployed at:

https://nexus.fd.io/content/repositories/fd.io.stable.YYMM.centos7/io/fd/hc2vpp/honeycomb/

Example: https://nexus.fd.io/content/repositories/fd.io.stable.1901.centos7/io/fd/hc2vpp/honeycomb/

• DEBs with the correct versions were deployed at

https://nexus.fd.io/content/repositories/fd.io.stable.YYMM.ubuntu.xenial.main/io/fd/hc2vpp/honeycomb/

Example: https://nexus.fd.io/content/repositories/fd.io.stable.1901.ubuntu.xenial.main/io/fd/hc2vpp/honeycomb/

• JARs with the correct versions were deployed at:

https://nexus.fd.io/content/repositories/fd.io.release/io/fd/hc2vpp/[path to artifact]/

Example: https://nexus.fd.io/content/repositories/fd.io.release/io/fd/hc2vpp/common/hc2vpp-parent/

Lay RC1 tag

Tag the RC1 bump commit:

git tag v1.19.01-RC1 -m "Hc2vpp v1.19.01-RC1"

Verify the tag locally:

git show v1.19.01-RC1

Push the tag to remote repository:

git push origin v1.19.01-RC1

Verify tag was pushed: https://gerrit.fd.io/r/#/admin/projects/hc2vpp,tags

Set version back to SNAPSHOT

Set maven versions of hc2vpp artifacts back to x.YY.MM-SNAPSHOT (example: 1.19.01-SNAPSHOT) for new development cycle.

Example (revert of RC1 bump): https://gerrit.fd.io/r/#/c/17066/

Make sure previous step was finished successfully before submitting the patch.

Update master branch

On master branch, bump versions of hc2vpp artifacts to next version snapshots (example: 1.19.04-SNAPSHOT).

Remember to also update versions in package scripts (files: prepare.sh, rpmbuild.sh and version).

Example: https://gerrit.fd.io/r/#/c/17056/

Create new project version in jira Hc2vpp releases and update release notes

Example: https://gerrit.fd.io/r/#/c/17067/

Bump jvpp version

Example: https://gerrit.fd.io/r/17068

Hc2vpp release procedure

Release procedure is similar to the steps for releasing RC1:

1. Set JVPP version to release version(1804 example: https://gerrit.fd.io/r/#/c/12156/).
2. Update release notes (1804 example: https://gerrit.fd.io/r/#/c/12284/).
3. Release hc2vpp (1804 example: https://gerrit.fd.io/r/#/c/12286/: poms + packaging/rpm/hc2vpp_version, packaging/rpm/release and vpp-version files). Make sure vpp_dependencies files DOES NOT specify single VPP version (would make hc2vpp point releeases required for every vpp point release).
4. Verify there are no issues with the artifacts in the stable repo.
5. Ask helpdesk@fd.io to copy artifacts from stable repos to release repos.
6. Lay tag:

git tag v1.18.04 -m "Hc2vpp v1.18.04"
git push origin v1.18.04

1. Bump hc2vpp version to .1 SNAPSHOT (1804 example: https://gerrit.fd.io/r/#/c/12287/: poms + packaging/deb/common/prepare.sh, packaging/rpm/hc2vpp_version, packaging/rpm/release, packaging/rpm/version and vpp-version files).