Page History

...

• 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, there what is little the incentive to participate in a release?
  
  

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.

...