Piotr and I have been contemplating moving Log4j BOM to its separate repository with its own release cycle. This need will become even more pressing as we start breaking down the Log4j modules to their own repository.
Ralph and Piotr already exchanged some ideas in #1526 <https://github.com/apache/logging-log4j2/issues/1526>. Since that ticket is irrelevant for the BOM discussion, I move the discussion to here. I think everybody agrees that we should separate modules to their individual repositories and, IMHO, this structure warrants a separate BOM project/repository that will act as a release train. We can further discuss when to cut releases for the BOM; every 6 months, in tandem with Log4j releases, etc. Ralph> We would have to think about that. I would think releasing Ralph> a new version of the BOM would be equivalent to a "Log4j Release". Ralph> We may, or may not, want to do that for a release of every sub-component. Can you explain why not? Ralph> From an ASF perspective I am not quite sure what should be deployed Ralph> to the dist location for those kinds of releases. Does the zip contain Ralph> artifacts from all the repos or just the bom pom.xml? Assuming `logging-log4j2` (where `log4j-bom` is removed!) will still have its own releases containing sources+binaries, and BOM will effectively only release a `pom.xml`, I don't see a need for complication here. Both the old `logging-log4j2` and the new `logging-log4j-bom` can follow their simple ASF release procedure just like `logging-log4j-tools` or `logging-log4j-transform`. Put another way, I don't think `logging-log4j-bom` releases should contain any binaries, sources, etc. of artifacts in its `dependencyManagement` block.
