For what it's worth, in HBase we've been approximating which Hadoop lines are EOL by looking at release rates and specifically CVE announcements that include an affected release line but do not include a fix for that release line. Our current approximation[1] lists 2.6, 2.7, and 3.0 as dead. So that lines up well with your proposed list.
[1]: http://hbase.apache.org/book.html#hadoop On Fri, Aug 16, 2019 at 5:14 AM Wangda Tan <wheele...@gmail.com> wrote: > > Hi folks, > > Want to hear your thoughts about what we should do to make some branches > EOL. We discussed a couple of times before in dev lists and PMC list. > However, we couldn't get a formal process of EOL. According to the > discussion. It is hard to decide it based on time like "After 1st release, > EOL in 2 years". Because community members still want to maintain it and > developers still want to get a newer version released. > > However, without a public place to figure out which release will be EOL, it > is very hard for users to choose the right releases to upgrade and develop. > > So I want to propose to make an agreement about making a public EOL wiki > page and create a process to EOL a release: > > The process I'm thinking is very simple: If no volunteer to do a > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > year). We will claim a release is EOL. After EOL community can still choose > to do a security-only release. > > Here's a list which I can think about: > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > 2) 2.7.x (Last released at Apr 2018) > 4) 3.0.x (Last released at May 2018) > > Thoughts? > > Thanks, > Wangda -- busbey --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
