I'm personally in favor of using a label. Besides myself, Sylvain, Benjamin, and Aleksey are probably the most likely to be keeping track of this. Any objections or alternatives from you guys?
On Fri, Dec 12, 2014 at 5:41 PM, Adam Holmberg <adam.holmb...@datastax.com> wrote: > As a Cassandra driver developer, I'm looking for a good way to keep track > of client-impacting changes and decisions in Cassandra. I'm aware of super > tasks like CASSANDRA-8043 > <https://issues.apache.org/jira/browse/CASSANDRA-8043> (native v4), and > others (schema migration > <https://issues.apache.org/jira/browse/CASSANDRA-6038>, schema > modernization > <https://issues.apache.org/jira/browse/CASSANDRA-6717>) via ad hoc > communication. > > Beyond feature changes, there is a class of decisions that might not change > existing functionality, but imposes certain limitations on clients using > new features. As an example, this week I learned of a decision to serialize > collections in v3 encoding, regardless of protocol: > https://issues.apache.org/jira/browse/CASSANDRA-8438 > > Presently, there is no aggregate view of new features, changes, and > decisions on issues that might impact client integration. > > In the discussion on CASSANDRA-8438 it was suggested that we might use > labels to tag issues with implications to client integrators, so I wanted > to float the idea here -- would maintainers be amenable to labeling > client-impacting issues in JIRA? > > > Adam > -- Tyler Hobbs DataStax <http://datastax.com/>
