Objectives for released artifacts:

• Offer users "something which consistently installs a stable state of an OPNFV release"
• Minimize the release engineering effort around packaging and maintenance of the packaging
• Install efficiency (efficiency of artifact download necessary to meet their needs)

Summary of options discussed:

Note: For OPNFV Arno:

• A.1b was required
• A.1a and A.2b were optional

Note: For OPNFV Brahmaputra :

• A.2b is required

TSC decision : http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-10-06-13.59.html VOTE: Voted on "Preference on minimum requirements on release artifacts?" Results are, A2b: 7, abstain: 1, A1b: 1 (ChrisPriceAB, 14:49:18)

A release is comprised of:

• A bootable disk image in .iso format per installer which offers an install capability for the jumphost
• documentation / release notes

A release is comprised of:

• A bootable disk image in .iso format per installer which offers an install capability for the jumphost. The .iso also includes all artifacts that a full OPNFV system requires. There is no need for the Jumphost to have connectivity to external repositories.
• documentation / release notes

A release is comprised of:

• A single bootable disk image in .iso format covering all installers which offers an install capability for the jumphost
• documentation / release notes

A release is comprised of:

• documentation / release notes on installing OPNFV from the tagged Git repository corresponding to the release

A release is comprised of:

• "deploy.sh" script per installer which offers an install capability for the jumphost (i.e. the script creates and brings up a VM on the jumphost, which subsequently drives the installation of the OPNFV system). The "deploy.sh" script can customized, so that the configuration that is desired by the user will be installed. "deploy.sh" relies on OPNFV and upstream repositories.
• documentation / release notes

A release is comprised of:

• A single "deploy.sh" script covering all installers which offers an install capability for the jumphost (i.e. the script creates and brings up a VM on the jumphost, which subsequently drives the installation of the OPNFV system). The "deploy.sh" script can customized, so that the installer and configuration that is desired by the user will be installed. "deploy.sh" relies on OPNFV and upstream repositories.
• documentation / release notes

Summary of approaches discussed:

Note: For OPNFV Arno approach "M.2b" is used.

Release definition and maintenance:

• "Releases" are defined by labeling in git. No branches are created.
• Releases are a "snapshot in time" - i.e. once a release is labeled it does not receive any further maintenance, i.e. its content is frozen and will not receive any updates or fixes. Access to a release is via its labels.
• Bug fixes and new features are provided in a continous way.

Release definition and maintenance:

• "Releases" are defined by labeling in git.
• A release is maintained and bug-fixes are applied to a release. I.e. there are always two active branches in OPNFV:
  • "latest" - artifacts that will become the next release
  • "stable" - the current release plus fixes on top of the most recent release (i.e. on top of the labeled artifacts of the most recent release).
• The "stable" branch will be available and stable at all times after the release until the next release.
  • Requires higher validation settings on stable for all changes

Example for this option:

• Brahmaputra released - Brahmaputra would be the "stable" release, C-River would become "latest"
• Fixes for Brahmaputra would be done and committed to "stable"
• No further maintenance for Arno would be done

Release definition and maintenance:

• "Releases" are defined by labeling in git.
• A release is maintained and bug-fixes are applied to a release until a new release comes out. I.e. there are always two active branches in OPNFV:
  • "latest" - artifacts that will become the next release
  • "stable" - the current release plus fixes on top of the released (i.e. labeled) artifacts.
• Snapshots of the "stable" branch will be released at regular intervals as "service releases" using labels.

Example for this option:

• Brahmaputra released - Brahmaputra would be the "stable" release, C-River would become "latest"
• Fixes for Brahmaputra would be done and committed to "stable"
• At regular intervals service releases of Brahmaputra would be created
• No further maintenance for Arno would be done

Release definition and maintenance:

• "Releases" are defined by labeling in git.
• The last k releases are maintained and bug-fixes are applied to the last k releases. I.e. there are k+1 active branches in OPNFV:
  • "latest" - artifacts that will become the next release
  • "stable" - the current release plus fixes on top of the most recent release (i.e. on top of the labeled artifacts of the most recent release).
  • …
  • "stable - (k-1)" - the release which is (k-1) versions older than the most recent release plus fixes on top of the most recent release.
• The "stable …" branches will be available and stable at all times.
• "k" would be a value defined by the TSC

Example for this option - with k=2:

• Brahmaputra released: Brahmaputra would be the "stable" release, C-River would become "latest", Arno would be "stable-1"
• Fixes for Brahmaputra would be done and committed to "stable"
• Fixes for Arno would be done and committed to "stable-1"
• Once C-River would be released, maintenance for Arno would stop.

Release definition and maintenance:

• "Releases" are defined by labeling in git.
• A release is maintained and bug-fixes are applied to a release until a new release comes out. I.e. there are n active branches in OPNFV:
  • "latest" - artifacts that will become the next release
  • "stable release n" - the current release plus fixes on top of the released (i.e. labeled) artifacts.
  • "stable release n-1" - the release prior to the current release plus fixes on top of the released (i.e. labeled) artifacts.
  • …
  • "stable release m" - Release m (in case m=1, this would be Arno) plus fixes on top of the released artifacts.
• Snapshots of the "stable" branches will be released at regular intervals as "service releases" using labels.
• "m" would be a value defined by the TSC