cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksey Yeschenko <>
Subject Re: JIRA Label for Client-Impacting Changes/Decisions
Date Tue, 16 Dec 2014 17:20:19 GMT
A label works for me.

But we also need a separate .txt file, or a section in NEWS.txt, for those who can’t, or
don’t want to follow the JIRA. Can’t realistically expect people to do that.


On December 16, 2014 at 8:15:43 PM, Tyler Hobbs ( wrote:

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 <>  

> 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  
> <> (native v4), and  
> others (schema migration  
> <>, schema  
> modernization  
> <>) 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:  
> 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 <>  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message