Thank you all for suggestions. Let me send a vote email to mark 2.6, 2.7, 3.0 EOL.
- Wangda On Wed, Aug 21, 2019 at 9:34 AM Akira Ajisaka <aajis...@apache.org> wrote: > +1 > > Thank you for the discussion. > > -Akira > > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <weic...@apache.org> > wrote: > > > > +1 > > I feel like one year of inactivity is a good sign that the community is > not > > interested in the branch any more. > > > > On Fri, Aug 16, 2019 at 3: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 > > > >
