Thanks for the pointer. That's clear enough for me. Thank you~
Xintong Song On Fri, May 22, 2020 at 3:32 PM Robert Metzger <rmetz...@apache.org> wrote: > Thanks for your response! > > The information about supported Flink releases is quite hidden, but it is > on the downloads page in the "Update Policy for old releases" section, and > it states: > > As of March 2017, the Flink community decided > > < > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Time-based-releases-in-Flink-tp15386p15394.html> > to > > support the current and previous minor release with bugfixes. If 1.2.x is > > the current release, 1.1.y is the previous minor supported release. Both > > versions will receive bugfixes for critical issues. > > > On Fri, May 22, 2020 at 9:19 AM Xintong Song <tonysong...@gmail.com> > wrote: > > > Thanks for bringing this up, Robert. > > > > +1 from my side on your proposal. > > > > Additionally, there's one question that I would appreciate if someone can > > clarify them. > > > > When talking about "all currently supported and unreleased Flink > > versions", *which > > versions are supported and which are not? *I've heard different versions > of > > stories about this. One version say that the Flink community only > supports > > the most recent 2 releases, which means currently (before 1.11.0 is > > released) only 1.10.x & 1.9.x are supported. Another say the most recent > 3 > > releases. However, I don't really find this information from any > > formal/credible sources, e.g. the project website. Maybe there is such > > information that I overlooked? If not, I would suggest to add it to our > > website. > > > > Thank you~ > > > > Xintong Song > > > > > > > > On Fri, May 22, 2020 at 2:07 PM Robert Metzger <rmetz...@apache.org> > > wrote: > > > > > Hi all, > > > > > > I have the feeling that the semantics of some of our JIRA fields > (mostly > > > "affects versions", "fix versions" and resolve / close) are not defined > > in > > > the same way by all the core Flink contributors, which leads to cases > > where > > > I spend quite some time on filling the fields correctly (at least what > I > > > consider correctly), and then others changing them again to match their > > > semantics. > > > In an effort to increase our efficiency, and since I'm creating a lot > of > > > (test instability-related) tickets these days, I would like to discuss > > the > > > semantics, come to a conclusion and document this in our Wiki. > > > > > > *Proposal:* > > > > > > *Priority:* > > > "Blocker": needs to be resolved before a release (matched based on fix > > > versions) > > > "Critical": strongly considered before a release > > > other priorities have no practical meaning in Flink. > > > > > > *Component/s:* > > > Primary component relevant for this feature / fix. > > > For test-related issues, add the component the test belongs to (for > > example > > > "Connectors / Kafka" for Kafka test failures) + "Test". > > > The same applies for documentation tickets. For example, if there's > > > something wrong with the DataStream API, add it to the "API / > DataStream" > > > and "Documentation" components. > > > > > > > > > *Affects Version/s:*Only for Bug / Task-type tickets: We list all > > currently > > > supported and unreleased Flink versions known to be affected by this. > > > > > > Example: If I see a test failure that happens on "master" and > > > "release-1.11", I set "affects version" to "1.12.0" and "1.11.0". > > > > > > > > > *Fix Version/s:* > > > For closed/resolved tickets, this field lists the released Flink > versions > > > that contain a fix or feature for the first time. > > > For open tickets, it indicates that a fix / feature should be contained > > in > > > the listed versions. Only blocker issues can block a release, all other > > > tickets which have "fix version/s" set at the time of a release and are > > > unresolved will be moved to the next version. > > > > > > *Assignee:* > > > Person currently working on the ticket. Assigned after conclusion on > > > approach by a committer. > > > Often, fixes are obvious and committers self-assign w/o discussion. > > > > > > *Resolve / Close:* > > > You can either Resolve or Close a ticket once it is done (fixed, > > rejected, > > > invalid, ...). > > > > > > As a rule, we Close tickets instead of Resolving them when they are > done. > > > > > > Background: There are semantic differences for Resolve and Close > > > (implementor vs reporter considers it done), but I don't see how they > > > practically apply to the Flink project. Looking at the numbers, Flink > has > > > 11066 closed tickets, and 3372 resolved tickets (that's why I propose > to > > > close instead of resolve) > > > > > > *Labels:* > > > "test-stability" for all test instabilities > > > "starter" for tickets suitable for new contributors > > > > > > *Release Note:* > > > Small notes that will be included into the release notes published with > > the > > > release. > > > > > > > > > *All other fields are not used not used on a regular basis.* > > > > > > Please +1 my proposal if you want it to be published in our Wiki like > > that > > > or let me know if I got something wrong here. > > > > > > Best, > > > Robert > > > > > >
