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. >> >>>>>> >> >>>> >> >> >> >> >> >> >
