That doesn’t really work: 1. As soon as there is some bug in it means someone has to go an create the repo and the appropriate scaffolding to get a release to work. No one will ever do it. 2. I release cannot consists of stuff from multiple repos. The distribution zip needs to contain everything in the release, which means the distribution module would have to be in the bom project. That saves me nothing when performing a release and makes it harder.
If you don’t want to support jmx-gui then propose we kill it. Ralph > On Mar 20, 2023, at 12:53 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > Hi Ralph, > > On Mon, 20 Mar 2023 at 15:09, Apache <ralph.go...@dslextreme.com> wrote: >> >> I would be comfortable with this if it is moved to its own repo and released >> first, then removed from the Log4J repo. I am not comfortable with “we can >> do it someday if we want to” unless we are dropping support for it. > > Can we keep 2.20.0 as current release and release a new version of > `log4j-jmx-gui` as soon as we fix some bug in it? > > `log4j-bom` is also mainly independent from the rest of the modules, > so we can move it to a separate repo. > > A Log4j2 release would technically consist of a release of `l-log4j2` > followed by a release of `l-l-bom` that bumps all versions (except > `log4j-jmx-gui`). > > Piotr
