Avocado is a set of tools and libraries to help with automated testing. One can call it a test framework with benefits. Native tests are written in Python and they follow the unittest pattern, but any executable can serve as a test.
There needs to be a way to define the cycle of Avocado-VT development phases which are not bound to be guaranteed compatibility with Avocado.
A proposal for those cycles was sent out in the past, but due to a lack of a tool or mechanism, it was not applied properly. One example of it being applied, though can be seen here:
CI: reinstate the waiver of failures with latest Avocado
This marks the point where the latest development (HEAD of master
branches) of Avocado-VT and Avocado are not guaranteed to be
compatible (to he extent that is being tested here).
The goal here is to allow for Avocado core changes that will affect
plugins without breaking Avocado-VT development. The following is the
proposed development cycles for Avocado:
1) Avocado 101.0 - bug fixes, improvements and core changes (possibly
affecting plugins)
2) Avocado 102.0 - bug fixes, improvements and core changes (possibly
affecting plugins)
3) Avocado 103.0 (LTS) - bug fixes, compatibility and usability
improvements only.
The compatibility check will be restored at the beginning of the
Avocado 103.0 development cycle, resulting in a Avocado-VT and Avocado
release that are compatible.
The definition of done is a clear mechanism that influences the release process producing Avocado-VT releases that are guaranteed to be compatible with Avocado.
There needs to be a way to define the cycle of Avocado-VT development phases which are not bound to be guaranteed compatibility with Avocado.
A proposal for those cycles was sent out in the past, but due to a lack of a tool or mechanism, it was not applied properly. One example of it being applied, though can be seen here:
The definition of done is a clear mechanism that influences the release process producing Avocado-VT releases that are guaranteed to be compatible with Avocado.