Or, ultimately, just release a BOM with all the related versions. And tie this BOM version release to the most frequent release, and adjust as needed.
T On Thu, Aug 31, 2023 at 11:27 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Mostly what matters is the release cadence (that is somewhat in line with > "what works with what'). > > Rule of thumb: if you have an artifact that SHOULD be released when > another is released, keep it together. > > Otherwise, no need to tie them together (disclaimer: yes, there is all the > clien side pain, what works with what, etc, but a site could explain that > just nicely, or, just provide a table of versions). > > My 5 cents, > T > > On Thu, Aug 31, 2023 at 3:38 PM Volkan Yazıcı <vol...@yazi.ci> wrote: > >> *[Sorry for the late response. I was busy with incorporating your input >> into the attack plan document.]* >> >> Thanks so much for the pointers and the insight Hervé (and Romain!), much >> appreciated! >> >> For those interested, Log4j's motivation and proposals are shared in this >> `dev@logging` thread >> <https://lists.apache.org/thread/9mz47opyjwtf15ylhd1h2k8r5lzydf2g>. If >> you >> have any feedback, I would be more than happy to hear. >> >> On Sat, Aug 26, 2023 at 2:03 PM Hervé Boutemy <herve.bout...@free.fr> >> wrote: >> >> > notice that you call it "multi-repo experience" >> > it's in fact more about a topic of component-oriented structure, each >> > component having its own release lifecycle. The fact that each component >> > has >> > his own Git repository is just an implementation detail (in the past, >> each >> > component had its own root directory in Subversion: see [1] for how we >> > went >> > from svn structure to Git one). >> > >> > > Would you still go the same route if Maven is founded today? >> > yes: Maven is a core, with plugins (and extension) = something we would >> > not >> > change without loosing critical aspects of Maven >> > and the fact that some plugins reuse some shared components is normal >> > >> > of course, the exact number of plugins and shared components could have >> > been >> > done with different granularity >> > >> > And on using Google repo tool and the precise directory organisation >> when >> > checking out everything, it's an implementation detail: >> > https://github.com/apache/maven-sources/tree/master >> > Changing anything here can be done, it's not critical: what is critical >> is >> > the >> > component-oriented approach. Then the granularity chosen for these >> > components. >> > >> > Regards, >> > >> > Hervé >> > >> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration >> > >> > Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit : >> > > Hi Volkan, >> > > >> > > Yes, I worked a lot on this aspect fo Maven: the result is summarised >> > here >> > > https://maven.apache.org/scm.html >> > > >> > > As you can see, you can get "Maven Full Sources" in one command using >> > Google >> > > "repo" tool. >> > > >> > > Please have a llok and we can dive into more details if you need >> > > >> > > Regards, >> > > >> > > Hervé >> > > >> > > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit : >> > > > Hello, >> > > > >> > > > Log4j crew is considering moving to a multi-repo structure. If I am >> not >> > > > mistaken, there are 125 `github.com/apache/maven-*` >> <http://github.com/apache/maven-*> >> > <http://github.com/apache/maven-*> >> > > > <http://github.com/apache/maven-*> repos, which makes me believe >> that >> > you >> > > > have quite a bit of experience with such a construct. I am curious >> to >> > hear >> > > > your thoughts on the matter. >> > > > >> > > > How does it work for you? >> > > > What are its advantages? >> > > > What are its disadvantages? >> > > > What are the things we should be extra cautious about? >> > > > Are there any major pillars we need to erect for such a construct to >> > work? >> > > > Would you still go the same route if Maven is founded today? >> > > > >> > > > I deliberately don't share in this post our goals with such a >> > migration to >> > > > avoid manipulating your line of thinking. I can do that later to >> give >> > the >> > > > conversation a little bit more context. >> > > > >> > > > Kind regards. >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > >> >
