We're in discussion to split out storm-kafka-client to have separate
release version and cycle. Since we have applied necessary changes to
storm-core of 1.1.x/1.0.x, unless storm-kafka-client needs more changes on
storm-core, storm-core 1.1.x/1.0.x should be compatible with
storm-kafka-client be compatible with storm-core 1.x.

I'm OK to keep the 1.0.x version lines specifically for storm-mesos (and
then we would end up keeping 1.1.x version line too) if we can't avoid the
case, but I couldn't guarantee all the bug fixes should be ported back to
1.0.x. We even often don't port back the bug fixes to 1.0.x version lines
when 1.1 is the active minor version of Storm unless the fixes are
critical. That means we may not port back the bug fixes to 1.1.x after
announcing 1.2.0 and 1.2.x-branch is cut. As we all know, it greatly
reduces the maintenance cost. It does make sense for storm-kafka-client to
do the backport for 1.1.x/1.0.x branches because huge changes are just
applied (though I guess the experiment described above may resolve such
issue), but not for others including storm-core except critical/blocker
issues.

So in storm-mesos view, it would be better to catch up with highest
possible version (that's why I hope to adopt storm-mesos in storm repo,
maybe not likely to happen for now), and I understand storm-mesos can't for
now because of Storm's issue. I wish the investigation of "Storm on X"
would occur actively sooner than later, so that it can be included as
earlier version of Storm 2.x (ideally 2.0.0 but it is just an ideal view).

Anyway, looks like there is no objection to announce 0.10.x/0.9.x
explicitly EOL.

- Jungtaek Lim (HeartSaVioR)

2018년 2월 14일 (수) 오전 6:02, Erik Weathers <eweath...@groupon.com.invalid>님이
작성:

> Thanks for keeping storm-mesos in mind Stig. :)  I'd be most worried about
> any issues we might see with the backported storm-kafka-client and how we
> *might* need to fix bugs in 1.0.x.  At least it should be easy to
> cherry-pick fixes back into 1.0.x after the backport-stomping of
> STORM-2937.
>
> Look forward to working with Bobby to get a long term plan for storm to run
> on mesos in 2.x+.
>
> - Erik
>
> On Tue, Feb 13, 2018 at 11:26 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com
> > wrote:
>
> > +1 to maintain 3 version lines, though we may want to look at what we can
> > do for storm mesos, which I think it currently stuck on 1.0.x.
> >
> > 2018-02-13 20:17 GMT+01:00 Hugo Da Cruz Louro <hlo...@hortonworks.com>:
> >
> > > +1 to maintain 3 version lines. Let’s properly announce that in our
> > portal
> > > and users list such that users know what’s coming.
> > >
> > > Agree with focusing on 2.0 which has a lot of improvements, rather than
> > > 1.x, x >= 3.
> > >
> > > > On Feb 13, 2018, at 10:43 AM, Alexandre Vermeerbergen <
> > > avermeerber...@gmail.com> wrote:
> > > >
> > > > +1 (non binding) to maintaining less version lines, provided that
> > > > 1.2.x branch is maintained long enough to allow progressive adoption
> > > > of 2.x
> > > >
> > > > Alexandre Vermeerbergen
> > > >
> > > > 2018-02-13 19:38 GMT+01:00 Priyank Shah <ps...@hortonworks.com>:
> > > >> +1 to maintaining 3 version lines as suggested by Jungtaek.
> > > >>
> > > >> On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" <
> > > ai...@hortonworks.com on behalf of ar...@apache.org> wrote:
> > > >>
> > > >>    +1 to maintain 3 version lines.
> > > >>
> > > >>    I think the next focus should be 2.0.0 than 1.3.0.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>    On 2/12/18, 11:40 PM, "Jungtaek Lim" <kabh...@gmail.com> wrote:
> > > >>
> > > >>> Hi devs,
> > > >>>
> > > >>> I've noticed that we are providing 4 different version lines
> (1.1.x,
> > > 1.0.x,
> > > >>> 0.10.x, 0.9.x) in download page, and I expect we will add one more
> > for
> > > >>> 1.2.0. Moreover, we have one more develop version line (2.0.0 -
> > master)
> > > >>> which most of development happens there.
> > > >>>
> > > >>> Recently we're releasing 3 version lines (1.0.6 / 1.1.2 / 1.2.0)
> > > >>> simultaneously and it took heavy effort to track all the RCs and
> > > verify all
> > > >>> of them. I guess release manager would take more overhead of
> > > releasing, and
> > > >>> it doesn't make sense for me if we continue maintaining all of
> them.
> > > >>>
> > > >>> Ideally I'd like to propose maintaining three version lines: 2.0.0
> > > (next
> > > >>> major) / 1.3.0 (next minor - may not happen) / 1.2.1 (next bugfix)
> > and
> > > >>> making others EOL (that respects semantic versioning and even other
> > > >>> projects tend to maintain only two version lines), but if someone
> > > feels too
> > > >>> aggressive, I propose at least we explicitly announce EOL to 0.x
> > > version
> > > >>> lines and get rid of any supports (downloads) for them.
> > > >>>
> > > >>> Would like to hear your opinion.
> > > >>>
> > > >>> Thanks,
> > > >>> Jungtaek Lim (HeartSaVioR)
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>

Reply via email to