As mentioned earlier in https://lists.apache.org/thread/96t7l66x8hlc5dswyt4g1mpn6wr5op4z, I would like to start a discussion about Impala deprecating support for older technologies that were retired by their creators: - Python 2: Officially retired on Jan 1st, 2020 ( https://www.python.org/doc/sunset-python-2) Operating system versions: - CentOS 7: End of Maintenance reached on June 30th, 2024 ( https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/ , https://endoflife.date/centos) - SLES 12: General support for 12.5 (the last minor release) ended on Oct 31st, 2024 - Ubuntu 16.04: Standard support ended in April 2021 ( https://ubuntu.com/about/release-cycle) - Ubuntu 18.04: Standard support ended in April 2023 Client connectivity: - support for the Beeswax client protocol: the default protocol for impala-shell was changed to HS2 in August 2020 (commit 179b14876d13353302d075be13f0ed1145041bfa), almost five years ago. This should have been long enough for all existing Impala clients to embrace HS2 as the client protocol, so Beeswax can now be marked for removal in the future.
- Support for Java 8 is another interesting question. Major OpenJDK rebuilds (Red Hat, Eclipse Temurin) show Java 8 support for 12-18 months moreIceberg removed support for Java 8 starting with their 1.7.0 release, so Impala will need to consider this any time we want to pick up any Iceberg release higher than 1.6.x. Considering all this, I don't think we need to make a decision on Java 8 support right now. Removing support for the above list certainly qualifies as a breaking change, which would prompt a major version change. The currently running Impala 4.5.0 release still contains support for all of the above, so this release could be a good opportunity to branch Impala 4.x and start working on Impala v5. This is a bit like the way Impala 4.x was started with https://lists.apache.org/thread/vkq8b4sb4j7x8yykbr92rw8c97k9n94q; so in a similar way I propose the following list: - release Impala 4.5.0 (the current release) with release notes expressly deprecating an agreed-upon set of technologies, - bump the version number to 5.0 on the master branch, - open the gates for breaking changes - eventually release v5.0 with breaking changes Creating a 4.x branch could be the subject of a separate (but related) discussion. Please share your thoughts, Thank you, - LaszloG
