+1 on arranging module names on storm-kafka and storm-kafka-client (with
versions).

Actually there's another trick behind storm-kafka-client.
storm-kafka-client 1.0.x supports Kafka 0.9.x and storm-kafka-client 1.1.0
(SNAPSHOT) supports Kafka 0.10.x, which can make a confusion. There was
also a question from mailing list regarding this.

The thing is how we name the module based on support version (naming
convention).


2016년 9월 21일 (수) 오전 8:48, P. Taylor Goetz <ptgo...@gmail.com>님이 작성:

> Now might be a time to consider making version-sensitive modules ((kafk,
> ES) maven multi-modules.
>
> I've never really liked "storm-Kafka" and "storm-kafka-client" as
> differentiators of Kafka 0.9..X and 0.10.x. I'd tend toward something like:
>
> storm-Kafka/
>     /0.9.x
>     /0.10.x
>
> I would think the same thing would apply to ES.
>
> I'm +1 for supporting both versions, with careful consideration wrt how
> and when  to deprecate or EOL support for a version line.
>
> -Taylor
>
> > On Sep 20, 2016, at 7:30 PM, Aaron Niskodé-Dossett <doss...@gmail.com>
> wrote:
> >
> > Thanks everyone. Could one or more committers +1 the PR that would
> support
> > both versions?
> >
> > https://github.com/apache/storm/pull/1337
> > On Mon, Sep 19, 2016 at 10:52 AM Satish Duggana <
> satish.dugg...@gmail.com>
> > wrote:
> >
> >> Agree with Bobby, +1 for supporting both versions till EOL and findout
> how
> >> many users are really using 1.7.x.
> >>
> >> ~Satish.
> >>
> >>
> >> On Mon, Sep 19, 2016 at 7:50 PM, Bobby Evans
> <ev...@yahoo-inc.com.invalid>
> >> wrote:
> >>
> >>> I am +1 for two modules until EOL.  Jan 2017. - Bobby
> >>>
> >>>    On Saturday, September 17, 2016 4:19 AM, Jungtaek Lim <
> >>> kabh...@gmail.com> wrote:
> >>>
> >>>
> >>> According to the link, last version line of ES1 (1.7.x) will be live to
> >>> Jan
> >>> 2017. We need to keep two versions at least EOL of that.
> >>> I wouldn't mind having two modules and also wouldn't mind having
> >> duplicate
> >>> codes, but it would be better if we can extract common parts to parent
> >>> module.
> >>>
> >>> Thanks,
> >>> Jungtaek Lim (HeartSaVioR)
> >>>
> >>> 2016년 9월 16일 (금) 오후 10:03, Aaron Niskodé-Dossett <doss...@gmail.com>님이
> >> 작성:
> >>>
> >>>> ES1 is close to end of life in terms of commercial support from
> >> Elastic,
> >>>> but not quite there (https://www.elastic.co/support/eol).
> >> Unfortunately
> >>>> the ES1 and ES2 clients won't interoperate with their opposite
> >> versions.
> >>>>
> >>>> Given that, I take it you would support having ES1 and ES2 bolts
> >> packaged
> >>>> separately?  This would somewhat like how we have storm-kafka and
> >>>> storm-kafka-client for different Kafka versions.
> >>>>
> >>>> Thanks! -Aaron
> >>>>
> >>>> On Thu, Sep 15, 2016 at 9:12 AM Bobby Evans
> >> <ev...@yahoo-inc.com.invalid
> >>>>
> >>>> wrote:
> >>>>
> >>>>> I personally don't use ES as part of my storm work, so I don't
> >>>> necessarily
> >>>>> feel qualified to answer this.  In general though I really do like to
> >>> see
> >>>>> storm come with batteries included.  If ES1 is not end of life, and
> >>> there
> >>>>> is a community of people who want to continue using it/supporting
> >> it, I
> >>>>> would say lets continue to do so.  If that is not true, or if ES
> >>> offers a
> >>>>> backwards compatible client that could sway things for me to say lets
> >>>> just
> >>>>> go forward with ES2. - Bobby
> >>>>>
> >>>>>   On Wednesday, September 14, 2016 2:47 PM, Aaron Niskodé-Dossett <
> >>>>> doss...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I started a a discussion about this a while ago, but didn't take it
> >> to
> >>> a
> >>>>> conclusion (my $realjob, etc., etc.).
> >>>>>
> >>>>> There are multiple PRs open to provide an Elastic Search 2.x bolt to
> >>> the
> >>>>> Storm project.  There are two different approaches:
> >>>>>
> >>>>> 1. Add side-by-side support for 2.x. Example:
> >>>>> https://github.com/apache/storm/pull/1337 (*FULL DISCLOSURE*: this
> >> is
> >>> my
> >>>>> own PR). [I also have some functionality enhancements in this PR, but
> >>>>> that's not relevant to this discussion.]
> >>>>>
> >>>>> 2. Upgrade existing bolt. Example,
> >>>>> https://github.com/apache/storm/pull/1396
> >>>>>
> >>>>> The drawback to approach 1 is that it duplicates a lot of code.  The
> >>>>> drawback to approach 2 is that it drops support for ES 1.x.
> >>>>>
> >>>>> ES 2.X has been out for a while and if we are serious about
> >> supporting
> >>>> it,
> >>>>> we need to have a way to write to ES 2.X.
> >>>>>
> >>>>> I believe approach number 1 is ideal (again, it's my own PR) and
> >>> possibly
> >>>>> deprecating the existing 1.X bolt.
> >>>>>
> >>>>> I'd love to hear thoughts from others!
> >>
>

Reply via email to