Did download page being reverted only from published site? I can see release notes are published (so I guess gitpubsub works well) but download page doesn't represent current storm-site. Is it due to LGPL issue on Storm 1.2.0?
2018년 2월 17일 (토) 오전 2:18, P. Taylor Goetz <[email protected]>님이 작성: > 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 <[email protected]> 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 <[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) > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >
