As part of the release process I updated the download page [1] to move older releases to archive.a.o as requested by INFRA. I also removed the “Current Release” sections for 0.9.x and 0.10.x to make it more clear that those lines are no longer supported.
If we want to add a more explicit statement to the download page, we can certainly do that as well. -Taylor [1] http://storm.apache.org/downloads.html > On Feb 13, 2018, at 4:45 PM, Jungtaek Lim <kabh...@gmail.com> wrote: > > 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) >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>
signature.asc
Description: Message signed with OpenPGP
