[
https://issues.apache.org/jira/browse/CASSANDRA-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730923#comment-14730923
]
Sylvain Lebresne commented on CASSANDRA-10146:
----------------------------------------------
A few minor remarks (which, outside of the 1st one which is a bug, are mostly
suggestions/nits):
* In {{CollectionType}}, what we want is get rid of {{enforceLimit}}, not
enforce it unconditionally.
* I think we could explicit both the 2.2 warning and the NEWS messages a bit.
Typically, for the 2.2 warning, I'd got with something like "Detected
connection using native protocol version %d. Both version 1 and 2 of the native
protocol are now deprecated and support will be removed in Cassandra 3.0. You
are encouraged to upgrade to a client driver using version 3 of the native
protocol", and some similar instruction on what people have to do in the NEWS
file.
* In {{Frame.java}}, can rename {{MODERN_LENGTH}} to {{LENGTH}} and can use it
directly in {{encode}} and {{decode}} rather than assigning it to a
{{headerLength}} variable.
* If we introduce {{Server.SUPPORTED_VERSIONS}}, which we'll have to maintain,
it makes more sense to check if the version received is contained in that list
in {{Frame.decode()}}. But truly, I would have simply added
{{MIN_SUPPORTED_VERSION}} instead, used that (and {{CURRENT_VERSION}}) for the
test and error message during frame decoding. That would avoid mistake like
forgetting to add a new version to {{SUPPORTED_VERSIONS}} (not that it's an
error that is likely to stay unnoticed for long, but the less you have to do
...).
> Deprecate v1 and v2 protocol in 2.2, drop support in 3.0
> --------------------------------------------------------
>
> Key: CASSANDRA-10146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10146
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Benjamin Lerer
> Labels: client-impacting, doc-impacting
> Fix For: 2.2.x, 3.0.0 rc1
>
>
> In 3.0, we would like to use frozen collections in the system keyspaces, and
> it seems likely that we will eventually want to use tuples or nested
> collections as well. Drivers that only support protocol versions 1 and 2
> will not be able to read these system keyspaces because they cannot decode
> those types.
> I think this is a good time to start deprecating and dropping support for old
> protocol versions. The v3 protocol was introduced in 2.1, so if we remove
> support for v1 and v2 in 3.0, that gives users two major versions to upgrade
> their drivers. Fortunately, upgrading drivers to a version that supports the
> v3 protocol is generally straightforward.
> The benefits of doing this are:
> * We can use new types in the system keyspaces
> * We can eliminate protocol-version-specific encoding and decoding of
> collections within Cassandra
> * Driver maintainers can eventually drop support for old protocol versions
> once all C* versions that support them are EOL
> To avoid a hard drop of v1 and v2 support in 3.0, I propose that we also
> officially deprecate these in 2.2. Unfortunately, we don't have
> protocol-level warnings until v4, so we can't use that to notify users of the
> deprecation, but the combination of a NEWS.txt entry, warning logs, and
> (potentially) driver-level warnings should suffice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
