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>님이 작성: > > > 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 > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >> >
