I kind of like the release train idea (quarterly or some regular cadence); that’s how some of the Spring projects have structured their own releases that combine several unrelated modules. I would be interested in details on what kind of release cadence we’d adopt.
> On Jul 7, 2023, at 12:00 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > On 2023/06/23 06:47:35 Volkan Yazıcı 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? > > I do not agree with Gary and Piotr that a BOM POM release should necessarily > be done when any artifact is released. If we break up Log4j into multiple > repos, which we should IMO, then it is possible (or likely) we would release > one during week 1 of the month another the next week and another the week > after that. That is just too much. It just becomes a PITA to release > components or we end up delaying releases so that we can do them all at once > - which I think is also a bad idea. But maybe I am worrying about nothing and > most of the components won’t ever be touched. > > OTOH, I do not believe releasing quarterly is a good idea either. > > This brings up another question. The BOM POM will be referencing artifacts > that will likely have dependencies on older releases of artifacts. For > example, if log4j-jdbc hasn’t been released in a while it likely will be > referencing an older release of log4j-core. The only way to fix that is by > releasing everything that has a dependency on log4j-core at the same time as > log4j-core. In that case we would be better off leaving things as they are. > > So before we start doing this I really want to understand what the full plan > for all of this is. > > Ralph
