Current state

We need processes (and preferably only a single process) that address the needs of our different target audiences:

OPNFV developers who work with upstream projects
NFV developers who want to use OPNFV as a standard platform, or to test new hardware platforms
Service providers who want to test and benchmark different hardware
(What other groups do we need to serve and what are their needs?)

A more elaborate description of target audiences and their needs can be found here: User stories for OPNFV release artifacts

The current release model which starts from the latest stable versions of upstream projects can produce stable releases. The benefits are

OPNFV releases have a steady, predictable cadence
The upstream project versions are already stabilized and most bugs have been fixed
There is always a well-defined "latest OPNFV release" with which for example the OVP program can work with
There is a community of people working with the same released version
Communication about the OPNFV releases is easier, since there is a well-defined release with a well-defined, tested feature set

The current OVP program assumes a reference platform containing only released upstream versions & which passes all planned compliance tests.

Issues with current state

Some of the issues with the current OPNFV release model are:

OPNFV developers who are working with upstream projects cannot use the OPNFV releases for development and testing, since the versions are older
If OpenStack will move to annual releases, then the OPNFV releases can have OpenStack versions that are several releases old
Installer projects have to support both old and recent versions of OpenStack
The current state also has the typical issues of the waterfall model: integration happens relatively late, there is a rush to integrate installers and CI testing, and testing before the release can take an unpredictable amount of time
- As a consequence, the release dates often slip
Making the releases take a lot of effort in the end, which can be problematic if the effort in OPNFV reduces
Some features that did not quite make it to the main release have come in a maintenance releases, which confuses the concept of a release
Sometimes the maintanance releases have fared worse in testing than the main release, since all effort is already going to the next release
The baseline for releases (OS packages, OpenStack and other upstream projects) can change, so the release is not really "stable": an installer for an OPNFV release pulls in packages from Linux distro repositories, from github etc and these upstream projects can change (as has happened already)
To make the progress towards a release transparent and predictable, the milestones must be enforced which takes some effort and requires some punishments for missing deadlines. This reduces the incentives to participate in a release
Overall, what is the incentive to participate in a release?

Goals for the release process

The release process should meet the requirements of the different stakeholders:

Serve different audiences requiring a different trade-off between recent/stable out of the same process (e.g. "Developers" and "End Users")
- The maturity of each installed version can vary, but it should be clear for the user how well tested the installed version is
It should be possible to uniquely identify the installed version
Every installation of the OPNFV stack should produce the same end result
The maturity of each installed version can vary, but it should be clear for the user how well tested the installed version is

Alternatives

One variant to the current system that has been discussed in the beginning of OPNFV is the right cadence for releases, such as

12 month release cadence: this would reduce the overall effort since the releases would come more seldom
1-2 month release cadence: the releases would be smaller, so hopefully less stressful
12 month releases with 1-month point releases: combines the benefits of both of above

An approach could be a process based on the CI evolution - a stepwise qualification for additional testing until an appropriate level of confidence is reached. Artifacts for different audiences can be taken from different stages of this pipeline. i.e. the process would be to determine when we want to make artifacts available from which stage of the pipeline, and what does that imply for the allocation of testing resources to the different pipeline stages at a given time.

Proposal

A concrete proposal on how the release process could look in the future is described in https://etherpad.opnfv.org/p/release-process2.0

However, there are still several open questions. The proposal is to set up a working group to define the release process

https://docs.google.com/presentation/d/1YURd7MAhcf2Vx-KTg7zdiavdDVTB8hnY0C2vHFLldE4/edit#slide=id.g37f06ebc6e_0_0

Next steps

Cloud native VNFs will need to extend CI to CD, some projects (e.g. Clover) are already working these aspects. We should start to think in this direction for the whole OPNFV process to include CD.
Any new resource requirements?

Browser not supported