Spring HAS to use a release train. There are simply too many artifacts. In addition, Spring users would get annoyed at having new Spring releases at random intervals and multiple times per month. This last part is the part I worry about Log4j, although perhaps our ecosystem isn’t large enough (yet) that it will be a problem.
Ralph > On Jul 7, 2023, at 10:59 AM, Matt Sicker <m...@musigma.org> wrote: > > 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 >
