Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Allow usage of circleci as well as ASF CI to cert beta and rc, record # consecutive required

...

Asterisks denote items that will require future work.

Note: We will maintain ongoing effort to ensure that the circleci testing suite as configured by the .circleci folder in the project root retains parity with ASF CI. See

Jira
serverASF JIRA
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyCASSANDRA-17930
for details on the initial push to achieve that parity.

Snapshot

  • A snapshot artifact is published for every commit to trunk. *
  • A retention window is associated with the snapshot artifacts.
  • Should not be used without collaboration/consultation with the developer community.
  • Will be discontinued / rewritten even if the idea validated.
  • Expectation that components of the core machinery may change, resulting in required code changes from the early adopters.  These breaking changes should be well-communicated.
  • As commits are made into trunk, contributors are encouraged to do extensive testing to ensure that no critical or severe bugs exist (e.g., data loss, consistency violations, incorrect responses to queries, etc). A clean test suite (unit, in-jvm and dtest) is mandatory with each commit.

...

  • Definition / Expectations:
    • From a user's perspective, the system is mostly “feature complete”
    • Usability is unpolished, and potentially changing on a frequent and regular basis.
    • Not ready for any user-impacting production usage, and recommended for development and testing only.
    • Should not be used without collaboration/consultation with the developer community.
    • A new major version is associated with the release, as it progresses from Alpha through EOL.
    • Interface and format changes may occur if necessary (i.e., a serious issue is identified during alpha testing) – but with strong preference to complete prior to alpha.
  • During this phase (actions):
    • An alpha release is made to have early adopters try it out and provide feedback in terms of the following
      • Compatibility with tooling and automation
      • Compatibility with client libraries
      • Validation of newly added features
      • Smoke Test of existing features for catching any regression
      • Performance evaluation
      • Stability at different levels of workload (throughput)
      • An alpha release is made to have early adopters try it out and provide feedback in terms of the following
    • For Apache Cassandra Users
      • Forward compatibility will not be provided for future alpha builds
      • This release is recommended for test clusters which can take long downtimes and also a cluster data wipe.

    ...

    • Definition / Expectations:
      • Should be interface-stable, so that consumers do not have to incur any code changes on their end, as the release progresses from Alpha through EOL.
      • Carries the same major version from Alpha.
      • Either circleci (app.circleci.com as configured by the .circleci folder in project) or ASF CI (https://ci-cassandra.apache.org/) can be considered as gatekeepers for a release. This requires ongoing effort to maintain parity between the test environments, however this should take place as part of us using circleci OR ASF CI as gatekeepers for commits.
      • For beta, we need a green run of circleci OR ASF CI to cut the release.
      • No new consistent regressions on ASF CI may exist when we cut the beta (i.e. don't make that worse).
      • We explicitly do not consider flaky tests on ASF CI infrastructure as beta release blockers (the vast majority are env specific as of 2022/10)No flaky tests - All tests (Unit Tests and DTests) should pass consistently. A failing test, upon analyzing the root cause of failure, may be “ignored in exceptional cases”, if appropriate, for the release, after discussion in the dev mailing list.
      • Following the first beta release, users can expect that SSTables generated by beta one or later will be fully compatible with future builds. Format changes will not be intentionally introduced, but may be if necessary to resolve issues identified during testing.
    • During this phase:
      • While product defects take precedence in prioritization in the project, issues with Beta are close behind that.
      • If there are no known bugs to be fixed before release, we promote to RC.
    • For Apache Cassandra Users
      • Forward compatibility for data will be provided for future beta releases
      • Rolling upgrades would not be provided for future beta releases
      • This release is recommended for test/QA clusters where short(order of minutes) downtime during upgrades is not an issue

    ...

    • Definition / Expectations:
      • A release candidate build is legitimately a release candidate. The final release will be built from the same SHA as the final release candidate.
      • Three consecutive green runs of circleci OR of ASF CI are required to cut RC
    • During this phase:
      • If no release-blocking issues are identified within a brief incubation period, release is promoted to GA.
      • The intent of this period is to allow for the user community to fully exercise the release and flag potential release-blocking issues.
      • Smoke tests are executed for each RC build published.
      • If bugs are found, fixes are made and above step is repeated.
    • For Apache Cassandra Users
      • Forward compatibility for data and rolling upgrades will be provided for future rc  releases
      • This release is recommended for less critical production systems.

    ...