+1 to all - deprecation to me means we add a label that we plan to remove it in 3.x, but we are not removing it not. We can step back.
Many of those modules don't look as if they need to belong in the main repo. I can accept kubernetes/docker stuff, but not in the main repo. I have a strong +1 on removing all JNDI features immediately, making them available for those poor souls in a separate repo. I opened another thread where I asked why we need this at all because it seems pointless to me. JNDI is also a hazardous word within this project. About the rest I don't have strong feelings On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote: > This is a vote to deprecate the following `2.x` modules and features > and remove them from the `3.x` release: > > * `log4j-cassandra`: > * CouchDB appender: > * `log4j-docker` > * GELF appender: > * Kafka appender: > * `log4j-kubernetes`: > * JeroMQ appender: > * JNDI-related features: > * `log4j-jpa`: > * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > * `log4j-mongodb3`: > * `log4j-spring-boot`: > * Java EE SMTP appender: > * Jakarta EE SMTP appender: > * `log4j-taglib`: > > Please cast votes for each module/feature separately on this mailing list: > > [ ] +1, drop the artifact/module, > [ ] +/-0 > [ ] -1, keep the artifact/module, because... > > This vote is open for 168 hours (i.e. one week) and each deprecation > will pass unless getting a net negative vote count. All votes are > welcome, but only the Logging Services PMC votes are officially > counted. > > Piotr
