Re: Drop 0. from the version

gt;>> class ingestion method (Kafka / Kinesis indexing service style) >> and >>>> SQL >>>>>>> being a first class query language. These are both, today, still >>>>>>

Re: Drop 0. from the version

gt; > > > > > the Incubator. Not sure how much this really matters, but > projects do > > > > it > > > > > > sometimes. > > > > > > > > > > > > Another question is, how often do we intend to rev the version? &g

Re: Drop 0. from the version

ould we intend to > > keep > > > > that > > > > > up, or slow it down by making more of an effort to avoid breaking > > > > changes? > > > > > > > > > > On Thu, Dec 20, 2018 at 2:17 PM Roman Leventov < > > leventov...@gmail.com> > > &

Re: Drop 0. from the version

; > > > changes? > > > > > > > > > > On Thu, Dec 20, 2018 at 2:17 PM Roman Leventov < > > leventov...@gmail.com> > > > > > wrote: > > > > > > > > > > > It may also make sense to distinguish "operations" breaking > changes > > > > from > > > > > > API breaking changes. Operations breaking changes establish the > > > minimum > > > > > > cadence of Druid cluster upgrades, that allow rolling Druid > > versions > > > > back > > > > > > and forward. I. e. it's related to segment format, the format of > > the > > > > data > > > > > > kept in ZooKeeper and the SQL database, or events such as > stopping > > > > > support > > > > > > of ZooKeeper for certain things (e. g. forcing using of HTTP > > > > > > announcements). So Druid cluster operators cannot update Druid > from > > > > > version > > > > > > X to version Z skipping the version Y, if both Y and Z have some > > > > > operations > > > > > > breaking changes. (Any such changes should support rollback > options > > > at > > > > > > least until the next version with operations breaking changes.) > > > > > > > > > > > > API breaking changes are just changes in Druid extensions APIs. > > Druid > > > > > > cluster operators could skip any number of releases with such > > > breaking > > > > > > changes, as long as their extension's code is updated for the > > latest > > > > > > version of API. > > > > > > > > > > > > On Thu, 20 Dec 2018 at 20:03, Roman Leventov < > leven...@apache.org> > > > > > wrote: > > > > > > > > > > > > > It doesn't seem to me that Druid API is going to stabilize in > the > > > > near > > > > > > > future (if ever), because there are so many extension points > and > > > > > > something > > > > > > > is broken in every release. On the other hand, Druid is not > > Hadoop > > > or > > > > > > > Spark, which have applications API. Druid API for extensions, > not > > > > > > > applications. It is used by people who are closer to Druid > > > > development > > > > > > and > > > > > > > fixing their extensions is routine. > > > > > > > > > > > > > > With that, I think it make sense to drop "0." from the Druid > > > version > > > > > and > > > > > > > call it Druid 14, Druid 15, etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Re: Drop 0. from the version

gt; > > API breaking changes. Operations breaking changes establish the > > minimum > > > > > cadence of Druid cluster upgrades, that allow rolling Druid > versions > > > back > > > > > and forward. I. e. it's related to segment format, the format of > the > > > data > > > > > kept in ZooKeeper and the SQL database, or events such as stopping > > > > support > > > > > of ZooKeeper for certain things (e. g. forcing using of HTTP > > > > > announcements). So Druid cluster operators cannot update Druid from > > > > version > > > > > X to version Z skipping the version Y, if both Y and Z have some > > > > operations > > > > > breaking changes. (Any such changes should support rollback options > > at > > > > > least until the next version with operations breaking changes.) > > > > > > > > > > API breaking changes are just changes in Druid extensions APIs. > Druid > > > > > cluster operators could skip any number of releases with such > > breaking > > > > > changes, as long as their extension's code is updated for the > latest > > > > > version of API. > > > > > > > > > > On Thu, 20 Dec 2018 at 20:03, Roman Leventov > > > > wrote: > > > > > > > > > > > It doesn't seem to me that Druid API is going to stabilize in the > > > near > > > > > > future (if ever), because there are so many extension points and > > > > > something > > > > > > is broken in every release. On the other hand, Druid is not > Hadoop > > or > > > > > > Spark, which have applications API. Druid API for extensions, not > > > > > > applications. It is used by people who are closer to Druid > > > development > > > > > and > > > > > > fixing their extensions is routine. > > > > > > > > > > > > With that, I think it make sense to drop "0." from the Druid > > version > > > > and > > > > > > call it Druid 14, Druid 15, etc. > > > > > > > > > > > > > > > > > > > > >

Re: Drop 0. from the version

pport > > > > of ZooKeeper for certain things (e. g. forcing using of HTTP > > > > announcements). So Druid cluster operators cannot update Druid from > > > version > > > > X to version Z skipping the version Y, if both Y and Z have some > > &g

Re: Drop 0. from the version

in Druid extensions APIs. Druid > > > cluster operators could skip any number of releases with such breaking > > > changes, as long as their extension's code is updated for the latest > > > version of API. > > > > > > On Thu, 20 Dec 2018 at 20:03, Roman Leventov > > wrote: > > > > > > > It doesn't seem to me that Druid API is going to stabilize in the > near > > > > future (if ever), because there are so many extension points and > > > something > > > > is broken in every release. On the other hand, Druid is not Hadoop or > > > > Spark, which have applications API. Druid API for extensions, not > > > > applications. It is used by people who are closer to Druid > development > > > and > > > > fixing their extensions is routine. > > > > > > > > With that, I think it make sense to drop "0." from the Druid version > > and > > > > call it Druid 14, Druid 15, etc. > > > > > > > > > >

Re: Drop 0. from the version

f API. > > > > On Thu, 20 Dec 2018 at 20:03, Roman Leventov > wrote: > > > > > It doesn't seem to me that Druid API is going to stabilize in the near > > > future (if ever), because there are so many extension points and > > something > > > i

Re: Drop 0. from the version

. On the other hand, Druid is not Hadoop or > Spark, which have applications API. Druid API for extensions, not > applications. It is used by people who are closer to Druid development and > fixing their extensions is routine. > > With that, I think it make sense to drop "0." f

Drop 0. from the version

. It is used by people who are closer to Druid development and fixing their extensions is routine. With that, I think it make sense to drop "0." from the Druid version and call it Druid 14, Druid 15, etc.