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