+1 for Gordon’s suggestion.
> On Jun 6, 2017, at 2:52 PM, Ted Yu <yuzhih...@gmail.com> wrote:
>
> +1
>
> bq. we can collect this list on the wiki
>
> Or utilize the Release Note field of JIRA for each such change.
>
> On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann <trohrm...@apache.org> wrote:
>
>> +1 for your suggestions Tzu-Li.
>>
>> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <tzuli...@apache.org>
>> wrote:
>>
>>> One suggestion for future major release announcements:
>>>
>>> I propose that we add a list of deprecated / breaking API changes in the
>>> announcement of major releases.
>>> Although @PublicEnvolving API is not guaranteed to not change across
>>> releases, it would still be nice that there’s a proper announcement when
>>> changing or deprecating them.
>>> Ideally, to avoid collecting the whole list during the release which most
>>> likely wouldn’t work, we can collect this list on the wiki during the
>>> development cycle.
>>>
>>>
>>> On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org)
>> wrote:
>>>
>>> Thanks a lot for all your responses on the point Till raised.
>>> It seems that we have an agreement to release this RC as Flink 1.3.0.
>>> I'll include a note into the release announcement regarding the state
>>> descriptor issue.
>>>
>>>
>>> Thanks also for all the release testing and the votes.
>>>
>>> +1 votes:
>>> - Chesnay
>>> - Robert (binding)
>>> - jincheng sun
>>> - Aljoscha (binding)
>>> - Gordon
>>> - Greg (binding)
>>>
>>> That's 6 votes, out of which 3 are binding.
>>> Therefore, I'll release RC3 as Flink 1.3.0!
>>>
>>>
>>>
>>> On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <trohrm...@apache.org>
>>> wrote:
>>>
>>>> I would be ok to quickly release 1.3.1 once the the respective PRs have
>>>> been merged.
>>>>
>>>> Just for your information, I'm not yet through with the testing of the
>>> type
>>>> serializer upgrade feature, though.
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter <
>>>> s.rich...@data-artisans.com> wrote:
>>>>
>>>>> +1 for releasing now and providing a 1.3.1 release soon.
>>>>>
>>>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gyula.f...@gmail.com>:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I also lean towards getting the release out as soon as possible
>> given
>>>>> that
>>>>>> it had been delayed quite a bit and there is no major issue
>> without a
>>>>>> straightforward workaround (agreeing with Nico and Kostas). I am
>> sure
>>>>> once
>>>>>> people will start using the new features we will see more issues
>> that
>>>>>> should be fixed asap in 1.3.1.
>>>>>>
>>>>>> Regarding the critical bug Till had found, we could add a line
>> about
>>> it
>>>>> to
>>>>>> the release notes so that people don't get blocked by it as there
>> is
>>> a
>>>>>> workaround possible.
>>>>>>
>>>>>> Regards,
>>>>>> Gyula
>>>>>>
>>>>>>
>>>>>> Kostas Kloudas <k.klou...@data-artisans.com> ezt írta (időpont:
>>> 2017.
>>>>> máj.
>>>>>> 31., Sze, 10:53):
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I also tend to agree with the argument that says a release should
>> be
>>>> out
>>>>>>> as soon as possible, given that 1) it improves
>>> usability/functionality
>>>>> and
>>>>>>> 2) at a minimum, it does not include new known bugs. The arguments
>>> are
>>>>>>> more or less aligned with Nico’s response on the matter.
>>>>>>>
>>>>>>> Focusing on the bug that spiked the current discussion, I agree
>> with
>>>>> Till
>>>>>>> that this is alarming, as it passed all previous testing efforts,
>>> but
>>>> I
>>>>>>> have to
>>>>>>> add that if nobody so far encountered it, we could release 1.3 now
>>> and
>>>>> fix
>>>>>>> it in the upcoming 1.3.1.
>>>>>>>
>>>>>>> Kostas
>>>>>>>
>>>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <
>> n...@data-artisans.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> IMHO, any release that improves things and does not break
>> anything
>>> is
>>>>>>> worth
>>>>>>>> releasing and should not be blocked on bugs that it did not
>> cause.
>>>>>>>> There will always be a next (minor/major) release that may fix
>> this
>>>> at
>>>>> a
>>>>>>> later
>>>>>>>> time, given that the time between releases is not too high.
>>>>>>>>
>>>>>>>> Consider someone waiting for a bugfix/feature that made it into
>>> 1.3.0
>>>>>>> who--if
>>>>>>>> delayed--would have to wait even longer for "his" bugfix/feature.
>>> Any
>>>>> new
>>>>>>>> bugfixes (and there will always be more) can wait a few more days
>>> or
>>>>>>> even a few
>>>>>>>> weeks and may be fixed in 1.3.1 or so.
>>>>>>>>
>>>>>>>>
>>>>>>>> Nico
>>>>>>>>
>>>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote:
>>>>>>>>> - Not sure whether it's a good argument to defer fixing major
>> bugs
>>>>>>> because
>>>>>>>>> they have not been introduced with 1.3.0. It's actually alarming
>>>> that
>>>>>>> these
>>>>>>>>> things have not been found earlier given that we test our
>> releases
>>>>>>>>> thoroughly.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
