[
https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17518250#comment-17518250
]
Bowen Song commented on CASSANDRA-17450:
----------------------------------------
[~bschoeni] I'm sorry but I disagree with your maintenance cost argument.
I don't deny it that in some circumstances maintaining code compatibility can
be painful and costly, such as Python 2 and 3, because there's just too much
difference between them. However, maintaining code for 3.6 to 3.10 is pretty
much painless, as long as you don't use the new added features. The Python
project is trying very hard to not break backward compatibility when
introducing new feature in minor version releases, and so far they've done a
pretty good job on that.
The two examples you gave, data classes and new typing support, do not break
backward compatibility in any way. For data classes, as long as you don't use
it, everything will work just fine. The typing support is even better than
that, as you can use it without breaking Python 3.6 compatibility. The typing
syntax is backward compatible, the older Python versions simply don't benefit
from the improvements made in Python 3.7.
Instead of making assumptions about how many users will still be using Python
3.6 when Cassandra 4.2, 4.3 or whatever version is released, why don't we just
sit back and wait? Since the overhead of maintaining Py36 backward
compatibility is pretty low, why do we have to agree on a specific
date/Cassandra version right now?
Also, I would like to point out aligning Cassandra EOL to RHEL/CentOS 7 EOL is
wrong. It's the Cassandra release date matters, not the previous version's EOL
date. Why is that? Let me give you an unrealistic example to explain this. We
know RHEL/CentOS 7 EOL is 2024. Now let's imagine Cassandra has a very long
support cycle and each version reaches their EOL in 10 years, and a new minor
version is released every year. In this scenario, Cassandra 99.0 was released
in 2014 and EOL in 2024, and Cassandra 99.1 was released in 2015 and EOL in
2025. We certainly can't drop Python 3.6 support in Cassandra 99.1 or 99.2 just
because Cassandra 99.0's EOL is after RHEL/CentOS 7's EOL. We should instead
drop the Python 3.6 support in Cassandra 99.10 or 99.11 which will be released
in 2024 and 2025 respectively.
> Drop python 3.6 support
> -----------------------
>
> Key: CASSANDRA-17450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17450
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
> Reporter: Brad Schoening
> Priority: Normal
> Fix For: 4.x
>
>
> Python 3.6 became EOL as of 12/23/21. There will be no further releases or
> security fixes for Python 3.6.
> https://github.com/httpie/httpie/issues/1177
> https://devguide.python.org/#status-of-python-branches
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
