Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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.

  * "**Latest**"
    * Fixed set of objects and artefacts defined by a specific OPNFV release (existing //or// planned). Rather than using a specific version of a particular component, the latest available components (could be binary artefacts or sources) from upstream repositories are used. 
    * The "latest" successfully deploys on a set of reference hardware/infrastructure (see below for "reference hardware"). Successful deployment means that all tests defined for the particular release (existing or planned) pass. Main objective of "latest" is to give developers and testers immediate feedback at system level.
    * OPNFV defined set of scenario tests associated with the release
    * "Latest" does not imply a “supported” release, rather is the “latest” working merge working towards the next target ‘release’ (future or maintenance) from OPNFV.
    * Does not imply anything more than Jenkins smoke-test and may/may not work (Users should be aware)

  * "**Reference hardware/infrastructure**"
    * Set of infrastructure to deploy an OPNFV release on (used for validation purposes)
    * Documentation of
      * Hardware used
      * Setup (cabling etc.) of the hardware
      * Configuration of the hardware and any associated software (e.g. management systems etc.)

    * 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'.
Wiki

User Tools

Site Tools

Page Tools
