Terminology discussion: "Release", "Latest", etc.

"Release"
- OPNFV defines a "release" as a fixed set of objects and artefacts marked at a specific point in time that will be supported as such. All objects and artefacts are tagged with a unique/specific version: Using the version it is possible to reproduce the "release" for as long as the "release" is supported by OPNFV (i.e. not deprecated).

The purpose of a release is to allow a consumer to use the object(s) in the course of a successful "deployment". A success deployment is defined as an "installation system based from a version release that satisfies all the criteria (tests) in terms of pass/fail. Its important to understand that the term "deployment success" can be subjective depending on end-users' expectations and environments, however in OPNFV we related back to our Reference Topology and Reference Environments with regards to testing and acceptance.

OPNFV delivers a set of scenario tests associated with the release that are traceable back to the Function Test Suite for that specific build/release.

Release content:
- Bootable disk image (ISO) used to install a Jumpstart Server
- Deployment tool that allows a user to perform autodeployment of the "release ISO". This deployment tool will allow the end-user to point to a specific patch-id/branch within OPNFV Gerrit so that the autodeployment is using the same artefacts as was used to generate the release ISO.
- Description of the reference hardware and its configuration that the code was tested on
- Description of all components/artefacts used in the release, including their individual versions (and if applicable, a reference to where these artefacts are sourced from).
- Documentation (installation and user-guide, release notes, licenses used, etc.) specific that release.
- Description of the tests performed along with the test results (pass/fail/skipped).
Approved by the TSC to be an official release of OPNFV with appropriate "Release Report" ensuring all "release criteria" (defined herein) has been met.
Community supported: Collections of bug-fixes etc. will be supplied as a "maintenance release" (see below), which has the same qualities as a "release".

"Maintenance release"
- Fixed set of objects and artefacts defined by a specific existing (i.e. already released) OPNFV release.
- The "maintenance release" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for a particular release pass (i.e Regression testing to ensure the Maintenance Release does not break additional things).
- "Maintenance release" content is the same as that of a "release" with the corrected features / functions
- A Delta Report/Change Report outlining the differences between "Main Release" and subsequent Maintenance (Service) Releases.

The purpose of a Reference Hardware is to provide a basis for end-users to development their own environments from and should not be interpreted as the "rule". Rather its a reference to establish a working release from, provide transparency to the methods and ways in which a "release" was established and a baseline for which to compare further releases, maintenance releases and other features against. Not meant to be exhaustive.

" Use of Releases / Maintenance Releases / Latest "
- As outlined above, this document is intended to provide a common-ground for terminology usage both within the OPNFV development community as well as for the consumers of the OPNFV production so that everyone has a common understanding and agreement of what we mean.
- From a Consumer Standpoint, the intention is that a end user will obtain what OPNFV produces (whether it be via a simple ISO, autodeployment from a tool, or fetching and building their own (in the case of "latest") and use the appropriate corresponding documentation to make use of that 'production'.