I think so far, we did not do much manual testing with respect to TTL. There is also an end-to-end test covering this area. We actually intended to include in the second RC but it was merged just after starting the creation procedure was started. Therefore I would like to include it if there is no strong objection.
On Mon, Aug 6, 2018 at 5:40 PM Chesnay Schepler <ches...@apache.org> wrote: > TBH I would prefer if we'd only include fixes for release blocking > issues in follow-up RCs. > > If you now include state TTL improvemements we effectively invalidate > any testing done so far in this area. > > On 06.08.2018 17:17, Till Rohrmann wrote: > > Yes, the next RC will also include FLINK-9938. > > > > On Mon, Aug 6, 2018 at 5:03 PM Aljoscha Krettek <aljos...@apache.org> > wrote: > > > >> Does this mean https://issues.apache.org/jira/browse/FLINK-9938 < > >> https://issues.apache.org/jira/browse/FLINK-9938> can move to 1.6.0 > from > >> 1.6.1 as well? > >> > >>> On 6. Aug 2018, at 17:00, Till Rohrmann <trohrm...@apache.org> wrote: > >>> > >>> Officially cancelling this RC in order to fix FLINK-10070. I will > publish > >>> the next RC later today. > >>> > >>> Cheers, > >>> Till > >>> > >>> On Mon, Aug 6, 2018 at 3:50 PM Till Rohrmann <trohrm...@apache.org> > >> wrote: > >>>> I agree with Chesnay and think that we should fix FLINK-10070 for > 1.6. A > >>>> PR fixing this issue is already open and can be merged in half an > hour. > >>>> > >>>> Since this change only affects the build, I would like to create a new > >> RC > >>>> with a shortened voting period until Wednesday evening (CET) which > would > >>>> end at the same time as this RC's voting period. > >>>> > >>>> Cheers, > >>>> Till > >>>> > >>>> On Mon, Aug 6, 2018 at 1:36 PM Chesnay Schepler <ches...@apache.org> > >>>> wrote: > >>>> > >>>>> Potential release blocked: Flink cannot be compiled with maven 3.0.X > >>>>> https://issues.apache.org/jira/browse/FLINK-10070 > >>>>> > >>>>> On 06.08.2018 11:21, Till Rohrmann wrote: > >>>>> > >>>>> Sure, only bugs will be fixed in 1.6.1. > >>>>> > >>>>> On Mon, Aug 6, 2018 at 10:34 AM Aljoscha Krettek < > aljos...@apache.org> > >>>>> wrote: > >>>>> > >>>>>> I don't think the fixVersion of all unresolved issues should be > >> updated > >>>>>> to 1.6.1. If they are not bugs they will not be fixed in 1.6.1 > >> anyways so > >>>>>> they should be updated to 1.7.0 or we can also remove the fixVersion > >> from > >>>>>> them entirely. > >>>>>> > >>>>>>> On 6. Aug 2018, at 10:16, Till Rohrmann <trohrm...@apache.org> > >> wrote: > >>>>>>> I think you're right that it is better to change the fixVersion > >>>>>> otherwise > >>>>>>> some issue might get wrongly attributed when they are merged in the > >>>>>> release > >>>>>>> branch after creating the RC. > >>>>>>> > >>>>>>> I will update the fixVersion of all unresolved issues to 1.6.1. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Till > >>>>>>> > >>>>>>> On Mon, Aug 6, 2018 at 9:56 AM Chesnay Schepler < > ches...@apache.org> > >>>>>> wrote: > >>>>>>>> Actually, this is defined in the release guide. > >>>>>>>> > >>>>>>>> > >> > https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release#CreatingaFlinkRelease-ReviewReleaseNotesinJIRA > >>>>>>>> On 06.08.2018 09:11, Till Rohrmann wrote: > >>>>>>>>> I'm not strictly sure whether there must not be any issues with a > >>>>>>>>> fixVersion of the current RC. At least in the past, we did not do > >> it > >>>>>> like > >>>>>>>>> this. Moreover, if a RC is canceled some of these issues might > >> still > >>>>>> go > >>>>>>>> in > >>>>>>>>> the actual release. > >>>>>>>>> > >>>>>>>>> However, I also see the point that the release notes are > confusing > >> as > >>>>>>>> long > >>>>>>>>> as the RC is not released. Once we release, JIRA will bump all > >>>>>> unresolved > >>>>>>>>> issues with a fixVersion of the release version to the next minor > >>>>>> release > >>>>>>>>> version. Then the release notes should reflect the truth. > >>>>>>>>> > >>>>>>>>> I think this we should clearly define how the community wants to > >>>>>> handle > >>>>>>>>> this situation and adhere to it with the next release. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Till > >>>>>>>>> > >>>>>>>>> On Sat, Aug 4, 2018 at 8:27 AM Chesnay Schepler < > >> ches...@apache.org> > >>>>>>>> wrote: > >>>>>>>>>> Elias is correct, when a RC is out no more open issuen should > >> exist > >>>>>> that > >>>>>>>>>> has a fixVersion for that version. > >>>>>>>>>> (An uncommon exception is the first RC which can be released for > >>>>>> testing > >>>>>>>>>> purposes.) > >>>>>>>>>> > >>>>>>>>>> On 04.08.2018 04:34, vino yang wrote: > >>>>>>>>>>> Hi Elias, > >>>>>>>>>>> > >>>>>>>>>>> Usually in order to make the release note clear and brief. It > >> will > >>>>>> only > >>>>>>>>>>> contain issues that have been fixed before the pre-release > branch > >>>>>> is > >>>>>>>> cut. > >>>>>>>>>>> For issues that are scheduled to be processed in this version > but > >>>>>> not > >>>>>>>>>>> processed, they will be postponed to the next minor or major > >>>>>> version. > >>>>>>>>>>> Thanks, vino. > >>>>>>>>>>> > >>>>>>>>>>> 2018-08-04 7:54 GMT+08:00 Elias Levy < > >> fearsome.lucid...@gmail.com > >>>>>>> : > >>>>>>>>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann < > >>>>>> trohrm...@apache.org> > >>>>>>>>>> wrote: > >>>>>>>>>>>>> The complete staging area is available for your review, which > >>>>>>>> includes: > >>>>>>>>>>>>> * JIRA release notes [1], > >>>>>>>>>>>>> [1] > >>>>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa? > >>>>>>>>>>>> projectId=12315522&version=12342760 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Shouldn't the release notes only include issues that have been > >>>>>> closed, > >>>>>>>>>> not > >>>>>>>>>>>> simple those that have a Fix Version equal to the release > >> version? > >>>>>>>>>> There > >>>>>>>>>>>> are a lot of issues with an assigned Fix Version that are > still > >>>>>> open. > >>>>>>>> > >>>>>> > >> > >
