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