OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VOTE] Release 1.6.0, release candidate #2


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 <aljoscha@xxxxxxxxxx <mailto:aljoscha@xxxxxxxxxx>> 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 <trohrmann@xxxxxxxxxx
    <mailto:trohrmann@xxxxxxxxxx>> 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
    <chesnay@xxxxxxxxxx <mailto:chesnay@xxxxxxxxxx>> 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
    <chesnay@xxxxxxxxxx <mailto:chesnay@xxxxxxxxxx>>
    >> 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.lucidity@xxxxxxxxx <mailto:fearsome.lucidity@xxxxxxxxx>>:
    >>>>>
    >>>>>> On Fri, Aug 3, 2018 at 9:23 AM Till Rohrmann
    <trohrmann@xxxxxxxxxx <mailto:trohrmann@xxxxxxxxxx>>
    >>>> 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.
    >>>>>>
    >>>>
    >>
    >>