Hi All. > * raise the Java requirements in 3.x to Java 17. +1 fine w/ me. FWIW, my day job is migrating from Java 11 to 17 ATM.
> * deprecate some modules in 2.x and drop them in 3.0.x, restore them if a > user requests it in 3.1.x. This feels arbitrary. First, we say 100k downloads, but then we say: - "a big company with an internal Maven repo counts 1" Count my day job in this category and our _large_ repo with _many_ products and _many_ maintained versions. - except "+ some modules under the line that are deemed important" by what criteria? What's the point of setting an arbitrary "bar" if we are going to make _further_ arbitrary exceptions? It's just simpler to have no bar since all decisions will be arbitrary; for example not having mongodb4 will be a problem for me looking ahead and probably for the user who just reported an issue in that code. Each module should be evaluated and kept if anyone says "-1, please keep it". Gary On Sat, Sep 9, 2023 at 3:15 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > In a Slack discussion Volkan proposed (among other things) to: > > * raise the Java requirements in 3.x to Java 17. It is the same > requirement as Spring Boot 3.x has, so I don't see a reason to lower > the bar. Besides Java 21 will be an LTS. > * deprecate some modules in 2.x and drop them in 3.0.x, restore them > if a user requests it in 3.1.x. > > While the number of downloads is not the only criterium (a big company > with an internal Maven repo counts 1, a student's project that tries > multiple version counts more), these are the stats for last month: > > 1 log4j-bom 35178445 > 2 log4j-api 30598923 > 3 log4j-core 15567816 > 4 log4j-to-slf4j 14036879 > 5 log4j-slf4j-impl 8675173 > 6 log4j-1.2-api 3454601 > 7 log4j-jul 2120049 > 8 log4j-web 1964937 > 9 log4j-layout-template-json 1760437 > 10 log4j-slf4j2-impl 1013605 > 11 log4j-jcl 566636 > 12 log4j-appserver 245029 > 13 log4j-iostreams 209990 > 14 log4j-spring-boot 87578 > 15 log4j-spring-cloud-config-client 38332 > 16 log4j-jakarta-web 37351 > 17 log4j-jpl 20295 > 18 log4j-flume-ng 14055 > 19 log4j-taglib 13989 > 20 log4j-couchdb 12781 > 21 log4j-mongodb4 4623 > 22 log4j-kubernetes 2618 > 23 log4j-jpa 1252 > 24 log4j-mongodb3 1143 > 25 log4j-docker 1122 > 26 log4j-cassandra 898 > 27 log4j-jakarta-smtp 741 > 28 log4j-jdbc-dbcp2 708 > 29 log4j-to-jul 297 > > I propose to have a bar at 100k, so we keep everything up to > `log4j-iostreams` + some modules under the line that are deemed > important. > > I would keep `log4j-to-jul`, mainly because it is a third > implementation of the Log4j API and I used it at work, when I didn't > get the permission to use Log4j Core. NB: the `2.x` version of > `log4j-to-jul` will still work with the `3.x` version of `log4j-api`, > but it might require a modularized version to be fully compatible. > > The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x > support drives it (Jetty 9.x reached EOL) more than the Tomcat > support. So we could even deprecate this one and create a > `log4j-tomcat` module or drop it entirely (I will pick up the Tomcat > part in my `eu.copernik` modules). > > Piotr > > PS: The downloads of the 3.x modules split from `log4j-core` are not > that great either. In the third column I renormalize them so that > `log4j-core` has 15M downloads: > log4j-core 78627 15567816 > 1 log4j-jdbc 55 10890 > 2 log4j-layout-jackson 55 10890 > 3 log4j-jndi 44 8712 > 4 log4j-script 44 8712 > 5 log4j-kafka 40 7920 > 6 log4j-jms 39 7722 > 7 log4j-csv 38 7524 > 8 log4j-jeromq 37 7326 > 9 log4j-smtp 37 7326 > 10 log4j-layout-jackson-json 33 6534 > 11 log4j-layout-jackson-xml 30 5940 > 12 log4j-layout-jackson-yaml 24 4752
