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