cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Hobbs <ty...@datastax.com>
Subject Re: JIRA Label for Client-Impacting Changes/Decisions
Date Tue, 16 Dec 2014 23:26:56 GMT
+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.holmberg@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 <sylvain@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 <aleksey@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 (tyler@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.holmberg@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/>

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