[
https://issues.apache.org/jira/browse/PHOENIX-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Yuan Jiang reassigned PHOENIX-7210:
-------------------------------------------
Assignee: Divneet Kaur
> Ensure Phoenix IT tests can be run against a real distributed cluster
> ---------------------------------------------------------------------
>
> Key: PHOENIX-7210
> URL: https://issues.apache.org/jira/browse/PHOENIX-7210
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Jacob Isaac
> Assignee: Divneet Kaur
> Priority: Major
>
> When planning a new Phoenix Release in OSS and subsequent upgrades in
> production, we must ensure that our release build is well tested. Currently
> running the IT test suite ensures that a version (build version) of client
> and server are working as desired. A few backward compatibility tests are
> also run as part of the IT test suite but they are very minimal in coverage.
> The purpose of this JIRA is to explore how we can enhance our IT test
> framework to provide test coverage and backward compatibility for various
> combinations of client-server versions.
> Our current OSS release sign-off process is as described
> [here|https://phoenix.apache.org/release.html]
> Apache Phoenix follows semantic versioning i.e. for a given version x.y.z, we
> have:
> * Major version:
> * x is the major version.
> * A major upgrade needs to be done when you make incompatible API
> changes. There will generally be public-facing APIs that have changed,
> metadata changes and/or changes that affect existing end-user behavior.
> * Minor version:
> * y is the minor version.
> * A minor upgrade needs to be done when you add functionality in a
> backwards compatible manner. Any changes to system table schema (for ex:
> SYSTEM.CATALOG) such as addition of columns, must be done in either a minor
> or major version upgrade.
> * Patch version:
> * z is the patch version.
> * A patch upgrade can be done when you make backwards compatible bug
> fixes. This is particularly useful in providing a quick minimal change
> release on top of a pre-existing minor/major version release which fixes bugs.
> When upgrading the Major/Minor version we typically run tests other than the
> IT tests to cover various client/server combinations that can manifest during
> an upgrade.
> 1. Client with old Phoenix jar + Servers with mixed Phoenix jars + old
> metadata (few servers have been upgraded)
> 2. Client with old Phoenix jar + Server with new Phoenix jar + old metadata
> (bits upgraded)
> 3. Client with old Phoenix jar + Server with new Phoenix jar + new metadata
> (metadata upgraded)
> 4. Client with new Phoenix jar + Server with new Phoenix jar + new metadata
> (clients upgraded)
> It would be a more exhaustive set of tests if we could run the Phoenix IT
> test suites against a distributed cluster with above combinations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
