In my opinion...
- Expected to find serious bugs (e.g. new poorly tested features): Block beta
- Anticipated to possibly find serious bugs (e.g. extensively changed features
with modest testing): Block RC
- Anticipated not to find serious bugs (e.g. old unchanged but poorly tested
features): Block GA
Which mostly accords with what you're saying re: today's state of play I think.
On 11/12/2020, 13:03, "Benjamin Lerer" <benjamin.le...@datastax.com> wrote:
It looks like my question raised more questions than I had in mind.
1. What is the meaning of the fix version?
2. When do we move from beta to RC?
3. Where does the Quality tickets fit in all that?
*What is the meaning of the fix version?*
It looks like we should just pick a definition and document it.
My preference would be 'The version in which the item must be fixed' (e.g
4.0-beta if the ticket must be fixed in a beta release).
*When do we move from beta to RC?*
The 2 things that I can get from the Release Lifecycle page are:
1. *No flaky tests - All tests (Unit Tests and DTests) should pass
consistently.*
2.* If there are no known bugs to be fixed before release, we promote to
RC.*
The first point is pretty clear, the second is a bit more vague. The main
reason for that is probably that there is a choice to make here. There are
some bugs that we cannot or chose to not fix in 4.0 (e.g. some LWT
consistency issues during cluster changes).
By consequence, I do not know if we can be more precise. We have to agree
on which known bugs we want to fix on the release. Once they are fixed and
we have the tests that pass constantly we should be able to cut an RC
release.
*Where does the Quality tickets fit in all that?*
That is for me the tricky question because the `Quality tickets` are really
about extending the test coverage and we probably did not think about that
type of work when the Release Lifecycle page was written.
We can decide to have (flaky tests + known bugs + increasing test coverage)
in beta and fix the documentation tickets in RC while waiting for people to
raise bugs or have (flaky tests + known bugs) in beta and (increasing test
coverage + documentation tickets) in RC.
I tend to prefer the (flaky tests + know bugs) in beta and (increasing test
coverage + documentation tickets) in RC approach. It reduces the scope for
the beta release and will increase our focus. Hopefully it might help us to
move faster.
I also hope that an RC release will push more people to test the release.
Increasing our confidence in the stability of 4.0.
What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
