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
