...
- 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. Recently, the Apex project stopped supporting the OPNFV releases for this reason
- 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
...
However, there are still several open questions. The proposal is to set up a working group to define the release process
Next steps
...