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 <[email protected]>님이 작성: > 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 < > [email protected] > > 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 <[email protected]>: > > > > > +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 < > > > [email protected]> 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 <[email protected]>: > > > >> +1 to maintaining 3 version lines as suggested by Jungtaek. > > > >> > > > >> On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" < > > > [email protected] on behalf of [email protected]> 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" <[email protected]> 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) > > > >> > > > >> > > > >> > > > > > > > > > > > > >
