Releasing the BOM every 6 months is not good IMO: It should be released every time one of its module is released, making it obvious that all latest versions work together _as should be expected_, otherwise we are putting the work on our users.
If we end up with one repository per jar file, it's going to become a random guessing game as to what works with what. Ideally, would want the parent POM of my each of my apps to depend on importing the latest Log4j BOM POM, giving me the latest and greatest of everything I need in my modules. Gary On Fri, Jun 23, 2023, 02:47 Volkan Yazıcı <vol...@yazi.ci> wrote: > 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. >
