Fair enough. I’ll apply the patches I have in mind to 1.1.x-branch and spin up a new release candidate.
-Taylor > On Jul 26, 2017, at 2:24 AM, Jungtaek Lim <kabh...@gmail.com> wrote: > > Replying inline. My only concern is about semantic versioning. If we don't > change the version of 1.x-branch and call this RC as 1.2.0 I would not have > any concerns. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > 2017년 7월 26일 (수) 오전 9:55, P. Taylor Goetz <ptgo...@gmail.com > <mailto:ptgo...@gmail.com>>님이 작성: > >> >>> On Jul 25, 2017, at 6:36 PM, Jungtaek Lim <kabh...@gmail.com> wrote: >>> >>> I believe I ported back complete set of bugfixes to the 1.1.x-branch >> when I >>> created 1.1.x-branch. >>> >>> 1.x-branch has some new features after 1.1.0, even also has backward >>> incompatible change: Redis state changed to binary. I included migration >>> script on it but still don't think it is bugfix. >> >> Is this a public API change or only internal? >> >> We've avoided it in the past by tying external components to storm >> releases, we can always change that, though it complicates releases. >> > > It is related to state data representation, so bound to internal change, > but users can't load their own old states before migrating and it will > throw error which makes users feel strange. > > IMHO 'bug fix' release exists to achieve minimal changes for only fixing > bugs which helps users to feel safer to upgrade. I'm OK to allow > exceptional cases if really needed, but would like to discuss and reach a > consensus before handling them to the cases. Ideally breaking the rule > (assuming we're respecting semantic versioning) should have clear reason to > do that. > > >> >>> >>> Taylor, which patches (only bugfixes) are important and not ported back >> to >>> 1.1.x-branch? If they're clearly about bugfix and possible to be ported >>> back, isn't it better to do that? >> >> Some fairly obvious ones that didn't feel specific to 1.2. Some are pretty >> critical. >> > > I'd be happy to help porting back if they need to be in 1.1.1. Could you > point out the issues? > > >>> >>> If they're not bugfixes but have feeling that we should include the >> release >>> ASAP, let's enumerate in another discussion shortly and apply them to >>> 1.x-branch when consensus has been made. >> >> We can certainly cut a new release for 1.1.1. Like I said earlier, I chose >> not to delete that branch so we could return to it if necessary. >> > > I'm even OK to cancel cutting a release for 1.1.1 and call it as 1.2.0, > since it brings same effect in current condition. > > >>> - Jungtaek Lim (HeartSaVioR) >> >> -Taylor >> >>> On Wed, 26 Jul 2017 at 5:17 AM Stig Rohde Døssing < >> stigdoess...@gmail.com> >>> wrote: >>> >>>> I ran into https://issues.apache.org/jira/browse/STORM-2659, which is a >>>> regression compared to 1.0.x, but not compared to 1.1.0. I think it >> would >>>> be nice to get fixed. >>>> >>>> 2017-07-25 20:59 GMT+02:00 Bobby Evans <ev...@yahoo-inc.com.invalid>: >>>> >>>>> We could do a 1.1.2 release sooner if needed. Technically any >> committer >>>>> can call for a release at any point in time. If there is a reason to >> do >>>> a >>>>> release (like an important fix for a critical component) then we can do >>>> it. >>>>> >>>>> >>>>> - Bobby >>>>> >>>>> >>>>> On Tuesday, July 25, 2017, 1:48:07 PM CDT, Alexandre Vermeerbergen < >>>>> avermeerber...@gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I guess 1.1.2 is going to be a few months away from now, so we'll have >> to >>>>> go with our own basic Kafka 0.10 Spout in the meantime... >>>>> >>>>> You can discard my previous vote, we'd need to at least download 1.1.1 >> rc >>>>> and give it a try to make an objective vote. >>>>> >>>>> Regards, >>>>> Alexandre Vermeerbergen >>>>> >>>>> 2017-07-25 19:38 GMT+02:00 P. Taylor Goetz <ptgo...@gmail.com>: >>>>> >>>>>> Hi Alexandre, >>>>>> >>>>>> STORM-2648 couldn’t be included because there is no patch available >> for >>>>> it >>>>>> yet. Once there is a patch available, it can go into the next release, >>>> so >>>>>> it’s certainly possible for it to be available in 1.1.2. >>>>>> >>>>>> -Taylor >>>>>> >>>>>> >>>>>>> On Jul 25, 2017, at 1:12 PM, Alexandre Vermeerbergen < >>>>>> avermeerber...@gmail.com> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> -1 (non binding) >>>>>>> >>>>>>> Maybe it's a bit selfish, but I really count on >>>>>>> https://issues.apache.org/jira/browse/STORM-2648 being part of Storm >>>>>> 1.1.1, >>>>>>> because we have a requirement to use Kafka 0.10 consumer in >>>> topologies >>>>>>> requiring at most once behavior. >>>>>>> >>>>>>> We understood that we could use storm-kafka-client with autocommit, >>>> but >>>>>>> then we're missing ack/fails and complete latency. >>>>>>> >>>>>>> We know that we could by-pass this limitation by implementing our own >>>>>> Kafka >>>>>>> 0.10 spout, but if possible it would be great to have Storm 1.1.1's >>>>> storm >>>>>>> kafka client cover the need of "at most once" requirements. >>>>>>> >>>>>>> Would it be possible to have this STORM-2648 to be part of 1.1.1 ? >>>>>>> >>>>>>> Best regards, >>>>>>> Alexandre Vermeerbergen >>>>>>> >>>>>>> >>>>>>> 2017-07-25 18:24 GMT+02:00 P. Taylor Goetz <ptgo...@gmail.com>: >>>>>>> >>>>>>>> Yes. There were a number of important patches present in 1.x-branch >>>>> that >>>>>>>> were not in 1.1.x-branch. >>>>>>>> >>>>>>>> When I tried to merge 1.x-branch to 1.1.x-branch, I ran into >>>>> unexpected >>>>>>>> conflicts. I thought about deleting 1.1.x-branch and recreating it, >>>>> but >>>>>>>> decided against it, not wanting lose changes there that we might >>>> want >>>>> to >>>>>>>> keep in case we wanted to revisit the contents of that branch. In >>>> the >>>>>> end I >>>>>>>> decided to cut the release from 1.x-branch. >>>>>>>> >>>>>>>> Jungtaek, I believe you created 1.1.x-branch… Do you know why/how it >>>>>>>> diverged? >>>>>>>> >>>>>>>> -Taylor >>>>>>>> >>>>>>>>> On Jul 25, 2017, at 12:08 PM, Stig Rohde Døssing < >>>>>> stigdoess...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Is it on purpose that this is cut from 1.x-branch and not >>>>> 1.1.x-branch? >>>>>>>>> >>>>>>>>> 2017-07-25 17:09 GMT+02:00 P. Taylor Goetz <ptgo...@gmail.com>: >>>>>>>>> >>>>>>>>>> This is a call to vote on releasing Apache Storm 1.1.1 (rc1) >>>>>>>>>> >>>>>>>>>> Full list of changes in this release: >>>>>>>>>> >>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_ >>>>>>>>>> plain;f=CHANGELOG.md;hb=88f0b8a45553ea960164fab18c736a5cdbae8e58 >>>>>>>>>> >>>>>>>>>> The tag/commit to be voted upon is v1.1.1: >>>>>>>>>> >>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h= >>>>>>>>>> 89bf57855806d84dba8d9b7fe6e76f9074a6aa19;hb= >>>>>>>> 88f0b8a45553ea960164fab18c736a >>>>>>>>>> 5cdbae8e58 >>>>>>>>>> >>>>>>>>>> The source archive being voted upon can be found here: >>>>>>>>>> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1. >>>>>>>>>> 1.1-rc1/apache-storm-1.1.1-src.tar.gz >>>>>>>>>> >>>>>>>>>> Other release files, signatures and digests can be found here: >>>>>>>>>> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1. >>>>> 1.1-rc1/ >>>>>>>>>> >>>>>>>>>> The release artifacts are signed with the following key: >>>>>>>>>> >>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_ >>>>>>>>>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>>>>> >>>>>>>>>> The Nexus staging repository for this release is: >>>>>>>>>> >>>>>>>>>> https://repository.apache.org/content/repositories/ >>>>>> orgapachestorm-1049 >>>>>>>>>> >>>>>>>>>> Please vote on releasing this package as Apache Storm 1.1.1. >>>>>>>>>> >>>>>>>>>> When voting, please list the actions taken to verify the release. >>>>>>>>>> >>>>>>>>>> This vote will be open for at least 72 hours. >>>>>>>>>> >>>>>>>>>> [ ] +1 Release this package as Apache Storm 1.1.1 >>>>>>>>>> [ ] 0 No opinion >>>>>>>>>> [ ] -1 Do not release this package because... >>>>>>>>>> >>>>>>>>>> Thanks to everyone who contributed to this release. >>>>>>>>>> >>>>>>>>>> -Taylor
