I think it is fair for Zipkin to deprecate a DB which upstream deprecates also. It is not the Zipkin project to blame for this policy or the speed at which these changes happen.
I do not think we need to remove support as soon as they deprecate though (no PR just to remove) but if a PR or a new functionality is stuck because of work needed for compatibility on a deprecated version, at that point is removed. People can stay in older Zipkin versions till they migrate. Is not like we break their current installation. Also, in general I think people use traces info as perishable data. I guess for many parties dropping the current data and gathering traces again is good enough and that should make transition easier. On Sun, Apr 21, 2019 at 5:14 PM Adrian Cole <adrian.f.c...@gmail.com> wrote: > Hi, team. > > There have been some interesting turns in Elasticsearch, and some > things that have always been around. TL;DR; we are being forced into a > corner where we have to immediately inherit Elastic the company's > version policy, and we need to figure out what to do about that. > > ## Licensed features people rely on > Elasticsearch has non-ASL code in their distribution for > authentication (X-Pack), and recently solved index load problems also > not in ASL [1]. Amazon is starting to address some of this in a fully > ASL different distribution, called OpenDistro [2]. Meanwhile, we have > significant problems due to performance. Elastic's "Basic Licensing" > may be ok for some sites, but it is also not ASL so difficult to > reason with. > > ## Constant upgrade burden, and fast deprecation > There have been significant problems caused on upgrade paths. Most > recently, ES changed their index naming convention, but also changed > the index template too [3]. Even with Phillip's help discussing the > problems, the ES community doesn't revert the most breaking changes.. > IOTW, we get morale support and guidance, but changes made by a few > people at Elastic burden us. This burden is increased as now, their > version policy is to support only the latest version and last minor. > For example, if everything breaks in 7, there's only one version > people can use.. the last version of 6 [4] > > ## What to do about this? > Elasticsearch is helpful in its own ecosystem, especially kibana, but > we seem to be at a crossroads for how to support our own ecosystems. > While it might be fine to dump ES 2.x support, it is probably hard to > ask people to immediately dump ES 5.x just because Elastic the company > released ES 7. If we revlock to Elastic the company's change policies, > I think users will just stop upgrading. However, I don't think we have > many choices but to follow their policy lock-step or, like we do with > mysql -> mariadb, pick a different distribution based on friendlier > license etc. OpenDistro is the only I know of, and not only is this a > new product, but it also only has ES 6.x at the moment. > > If we adopt Elastic the company's policy lockstep, I think our first > apache release we "may" be able to still support the current version > range, but it largely depends on what's accepted in their hadoop > library [4]. We may still be able to hack by shading an entire library > tree just for ES 2.x.. > > Regardless, we should warn the community that it may not be possible > for us to support the dependencies job, if not ES itself, more than > Elastic the company's policy. > > Thoughts? > -A > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dzipkin_issues_2369-23issuecomment-2D464844264&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=tNZUubhuSpaRUK46kmY9KGUxbpKilTBk1SVTQ-eO3vI&e= > [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_opendistro-2Dfor-2Delasticsearch_security&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=NoOBn6nn6wfYYvlI_2ON35p01CZycE_P57SiwjQXPjY&e= > [3] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.elastic.co_guide_en_elasticsearch_reference_7.x_breaking-2Dchanges-2D7.0.html&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=gsk8IU5eslt39FQiX5sg-Qq7r90b9hTskLYPL4L5Tug&e= > [4] > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_elastic_elasticsearch-2Dhadoop_issues_1277&d=DwIBaQ&c=fi2D4-9xMzmjyjREwHYlAw&r=Tbt5RfqX8JsodFyDrWf9DA8aXKZqHT-1uWccMDaGFlY&m=UGyxtS5mB-1hqFnhRydLxTnPFthNZJPG-JNtWeOfGY8&s=WvGazsTiZCquaZI2YSDJt0KVh8upURR14z9njDO37as&e= > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@zipkin.apache.org > For additional commands, e-mail: dev-h...@zipkin.apache.org > > -- *Jordi Polo Carres* | API bundle lead | Medidata Solutions Worldwide <http://www.mdsol.com/> Api bundle: api-bun...@mdsol.com API standard: https://learn.mdsol.com/display/CA/MCC+API+Standard+V1
