On Mon, Sep 24, 2018, at 11:11, Gwen Shapira wrote: > Can you explain more why we can't add "incremental" to the existing API and > then deprecate the old behavior? The "rejected" section says: "We would > also not have been able to deprecate the non-incremental mode." but I'm not > sure why not.
Hi Gwen, We talked about this previously. If we extend the existing API, then we can't change the behavior of existing programs, which means that non-incremental needs to continue to be the default. Changing the default to incremental would be a breaking change which would silently alter the behavior of existing programs. Also, the actions of append, subtract, etc. don't fit in the existing API. > > Having two APIs "Alter" and "Modify" with slightly different behavior that > is not obvious from their name (i.e. would anyone remember which one is > incremental?) seems pretty bad. The KIP doesn't propose having two APIs named "alter" and "modify". The new API is named IncrementalAlterConfigs. best, Colin > Add the fact that in databases, "alter" is > incremental and things will get confusing pretty fast. Obviously if > deprecating the old behavior is impossible, than we have no choice - but I > don't see why it would be impossible. > > Gwen > > On Mon, Sep 24, 2018 at 10:29 AM Colin McCabe <cmcc...@apache.org> wrote: > > > > Hi all, > > > > I would like to start voting on KIP-339, which creates a new > IncrementalAlterConfigs API. > > > > The KIP is described here: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-339%3A+Create+a+new+ModifyConfigs+API > > > > Previous discussion: > > https://sematext.com/opensee/m/Kafka/uyzND1OYRKh2RrGba1 > > > > best, > > Colin > > > > -- > Gwen Shapira > Product Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog
