I agree that 1.x is ready for EOL and I too feel bad for users that take time to work in Bugzilla. Closing Bugzilla will just make some users create Jira tickets though. It might still be good to have an apache place where users can collect 1.x patches and discuss 1.x issues that we can still monitor, especially since there is much information already there. Keeping it read only does not quite fit that bill but i get weary of typing "not actively maintained". I guess closing might help send a clearer message. I see that Struts starts at 2.0 in Jira. Do we all feel that 2.x has all the features and compatibility needs to shut down? Seems like yes to me. Rolling file appenders need some tweaks imo and we have tickets for that. I do like the struts FAQ and especially the last entry. I have a big proprietary app server at work on 1.x and started a branch to port it to 2.x last year but I got stalled when it came time to porting our custom appenders and custom initialization code. It's just too much work. If I had to redo it I would start with using the 1.2 compatibility jar to get to dealing with our custom bits sooner. That's what I would advise people to do. Gary
-------- Original message -------- From: Christian Grobmeier <grobme...@apache.org> Date: 07/04/2015 02:30 (GMT-08:00) To: Log4J Developers List <log4j-dev@logging.apache.org> Subject: [DISCUSS] EOL for Log4j 1.x Hi all, we are actively working on Log4j 2.x, but Log4j 1.x hasn't been touched since the last release. I was doing the last one, and I can't see I will find the time or motivation in any time to roll out another one. Nobody else stood up since then. That's OK, because I can observe the community adapting Log4j 2. No numbers, just feelings. I would like to propose to mark an EOL date for Log4j 1.x by the end of the year. As we don't fix things (most likely) with 1.x, this is not about "maintenance" at all. The future date might be more or less our signal that we want to actively help our users migrating to 2.x. We can use the remaining time to write or improve documentation, maybe even write some migration tool. In the announcement we should highlight the history of Log4j 1, it's problems and why we think Log4j 2.x is the best way to log in Java today. Let me know what you think about this idea. All feedback - committer or not - is welcome. I suggest we leave this discussion open until we reached an agreement or at least one week, so everybody got a chance to look into this. Regards, Christian --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
