+1 on starting a new label. Feel free to start labelling. Other tickets that should be labelled: * https://issues.apache.org/jira/browse/CASSANDRA-7536 * https://issues.apache.org/jira/browse/CASSANDRA-7523
Note: I also created https://issues.apache.org/jira/browse/CASSANDRA-8495 to document type serialization formats in the native protocol spec. On Tue, Dec 16, 2014 at 2:44 PM, Adam Holmberg <adam.holmb...@datastax.com> wrote: > > I think the issue that brought this up was more about collection > serialization. Since collections existed before v3, it was surprising to > see outer collections serialized with one format and inner with another. > > I'm not questioning that decision, nor do I want to operate in > 'undocumented territory'. What I do want to do is find a good way to know > when these assumptions are made. I was hoping a label would help in being > applied across different categories of decisions that impact clients. > > I didn't hear any strong opposition to trying the label. Is anyone allowed > to create them? If so, I'll start applying it to the things I know about. > Are there other issues that haven't been mentioned previously in this > thread? > > Thanks, > Adam > > On Tue, Dec 16, 2014 at 12:56 PM, Sylvain Lebresne <sylv...@datastax.com> > wrote: > > > We already try to use labels (though we definitively haven't always done > it > > in the past): all protocolv4 stuffs should have a protocolv4 label, and > I'm > > all for continuing to stick to it. I'm fine having an additional "driver > > impacting" tag for stuff that are likely to need special driver handling > > (as it's probably not limited to protocol stuffs). And I'm not strongly > > against a section in the NEWS file, though we've already have a changelog > > in the spec itself and it kinds of feels like a better place. > > > > But honestly, regarding the issue that raised this, it's not so much that > > we made a decision to do something new for the protocol v2: UDT are just > > not natively supported by the protocol v2 (for the simple reason that > they > > didn't existed when the v2 was done). As far as v2 is concerned, UDT are > an > > opaque "custom type". If you want to support UDT in your client, you > should > > officially support v3. You're free to try to support UDT nonetheless in > v2, > > and some drivers do, but you're in undocumented territory. > > > > > > On Tue, Dec 16, 2014 at 6:20 PM, Aleksey Yeschenko <alek...@apache.org> > > wrote: > > > > > 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. > > > > > > -- > > > AY > > > > > > On December 16, 2014 at 8:15:43 PM, Tyler Hobbs (ty...@datastax.com) > > > 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 < > > 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/> > > > > > > -- Tyler Hobbs DataStax <http://datastax.com/>
