On Sat, 10 Feb 2024 at 16:27, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> Hi All:
>
> I want to focus on content before we decide what label to put on the
> next release. Then, we can see if we want to break binary
> compatibility (BC) for a Commons Logging 2.0.0.
>
> My main driver for the next version is to drop support and dependency
> on the Log4j 1.x JARs file(s). I speak of JAR files here as opposed to
> APIs, see below.
>
> I see several ways to drop Log4j 1.x JARs.
> 1) Replace the dependency on Log4j 1.x with the Log4j 2 compatibility
> JAR for 1.2: org.apache.logging.log4j:log4j-1.2-api
> This maintains BC and can become 1.4.0.
> 2) A re-implementation of Log4JLogger where all methods call Log4j 2 APIs.
> This maintains BC and can become 1.4.0.
> It looks like this is not possible in a straightforward manner
> because we have Log4j 1 classes in the public API, specifically
> org.apache.commons.logging.impl.Log4JLogger.Log4JLogger(Logger). It
> might not be worth hacking around that if that's even possible.
Isn't that much the same as re-implementing option 1?
> 3) A hard delete of org.apache.commons.logging.impl.Log4JLogger (the
> class is deprecated in 1.3.0 FWIW).
> This breaks BC and requires a 2.0.0 with a package name and Maven
> coordinate change.
> The package would change from org.apache.commons.logging to
> org.apache.commons.logging2.
> The Maven coordinates would change from
> commons-logging:commons-logging to org.apache.commons:commons-logging2
> 4) A gutting of Log4JLogger where all methods are no-ops.
Surely it would be better to throw an Exception rather than
silently drop what could be important info?
> This maintains BC and can become 1.4.0.
> I like (1) the best, it gives us a clear path to a 1.4.0 without
> breaking BC and removes dependencies on the 1.x jars.
> From my POV breaking BC in Logging 1.x is a non-starter.
>
> Then, if we want to remove support for the Log4j 1 API (the JAR is
> already gone at this point), that would necessitate a 2.0.0.
>
> Gary
>
> On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold
> <elh...@ibiblio.org> wrote:
> >
> > I'd like to plan and start working on a 2.0 release of commons-logging
> > with the specific goal of resolving the large number of out of date,
> > unsupported, old libraries that this project pulls into so many
> > dependency trees. There's been some discussion of a 2.0 release in
> > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187
> > but I'd lik to bring this to a wider audience. Specifically my
> > thoughts are:
> >
> > 1. 2.0 will be technically API incompatible since it will remove all
> > traces of EOL libraries like log4j 1.x and avalon.
> > 2. It will otherwise be a drop-in replacement for anyone not using
> > these old libraries. Specifically:
> > * Other deprecated methods are not removed.
> > * The package name does not change.
> > * The group ID and artifact ID do not change.
> > * Minimum Java version remains 1.8
> > 3. It can include any recent, API compatible bug fixes and new
> > features that are available at HEAD, but these are not blockers.
> >
> > While there are other more incompatible changes that could be made in
> > a major version bump, I think it's really important to produce a
> > drop-in replacement that is friendlier to security scanners and
> > dependency analyzers. I do not want to discourage people from
> > upgrading for any reason other than they're still using EOL libraries
> > like log4j 1.x.
> >
> > 1.3.0 was recently released and seems up to date with the last several
> > years of changes and bugs, so it feels like a good time to make the
> > break. Anyone who isn't ready to give up their decade+ old loggers can
> > stay on this release for a while. However if there's a strong need to
> > maintain a 1.x branch that could be done too. Or we could start 2.x
> > as a separate branch.
> >
> > If this achieves rough consensus, I can start sending PRs. However,
> > the final release would require a commons committer or perhaps PMC
> > member to take over.
> >
> > Thoughts?
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
