Hi all,
On Sun, 3 Sept 2023 at 22:37, Ralph Goers wrote:
> Here is my position on this.
>
> 1. We don’t change the repo layout for 2.x. It is too late in the game for
> that as 2.x should be moving to maintenance mode.
> 2. Lpg4j API should be separated - both with its own repo and a separate w
Here is my position on this.
1. We don’t change the repo layout for 2.x. It is too late in the game for
that as 2.x should be moving to maintenance mode.
2. Lpg4j API should be separated - both with its own repo and a separate web
site.
3. I would separate the rest as:
log4j2 - core, p
Hi Gary,
On Sat, 2 Sept 2023 at 14:36, Gary Gregory wrote:
> So any time you release any jar, the BOM is updated?
The current `log4j-bom` artifact should probably be released each time
(or shortly after the last release if multiple releases are close
together).
However we can also introduce oth
I am not able to follow. Granted nobody is proposing an ossified BOM that
is rarely released, mind explaining why would my statement be an argument
against multi release cycles?
Could you give an example of how multi release cycles funnelled through the
release of a BOM project will disrupt the wo
On Sat, Sep 2, 2023 at 11:39 AM Volkan Yazıcı wrote:
> Maybe, maybe not. PMC will decide on the release timing of the BOM.
>
Right, so maybe it's an argument in favor of your point or maybe it's an
argument against! ;-)
Gary
>
> On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory
> wrote:
>
> > On S
Maybe, maybe not. PMC will decide on the release timing of the BOM.
On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory wrote:
> On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote:
>
> > > For me, there is one kind of "user"
> >
> > As Piotr indicated we have multiple user groups. As stewards of this
>
On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote:
> > For me, there is one kind of "user"
>
> As Piotr indicated we have multiple user groups. As stewards of this
> project we should take these into account, not just our personal agenda.
> The current release model where everything shipped all
On Sat, Sep 2, 2023 at 8:35 AM Gary Gregory wrote:
> On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı wrote:
>
>> > For me, there is one kind of "user"
>>
>> As Piotr indicated we have multiple user groups. As stewards of this
>> project we should take these into account, not just our personal agend
> For me, there is one kind of "user"
As Piotr indicated we have multiple user groups. As stewards of this
project we should take these into account, not just our personal agenda.
The current release model where everything shipped all at once doesn't
cater for all such use cases.
> For me, there
Hi Herve,
On Fri, 1 Sept 2023 at 09:10, Herve Boutemy wrote:
>
> it's not "mono vs multi (Git) repo setup" but "monolithic vs
> component-oriented release"
Thanks for putting the discussion back on track. I think we could look
at what other logging frameworks do.
Ceki's SLF4J/Logback has:
* o
Hi Piotr,
Thank you for your detailed response :-)
My comments are inline below.
On Thu, Aug 31, 2023 at 4:59 PM Piotr P. Karwasz
wrote:
> Hi Gary,
>
> May I offer a different perspective on this.
>
I knew that ;)
>
> On Wed, 30 Aug 2023 at 18:56, Gary Gregory wrote:
> > - I like a mon-re
Hi all,
I agree that the discussion should have been framed differently. It
immediately reminds me of a headache I never have: To pick up a new version
of Jetty, I just update a property in my POM. That's all I need to pick up
the 170 modules Jetty provides (not sure how many are jars). I know it'
Thanks for sharing your thoughts Herve, much appreciated!
Completely agree with you that the discussion should have rather focused on
the "monolithic vs component-oriented release" subject. Thanks for pointing
this out! (I am partly to blame for not capturing the context right.)
Regarding how to
additional notice: on implementing component-oriented approach
from a tooling perspective, experience proves that the hard part is not at Git
level, but at generated Maven site level = how to replace a unique Maven site
for the monolithic release with a site that is a combination of multiple
co
it's not "mono vs multi (Git) repo setup" but "monolithic vs component-oriented
release"
longer explanation:
IMHO, you should frame the discussion about:
1. keeping unique global/monolithic release of all log4j
vs
2. splitting log4j into multiple parts/components released separately (with
depend
Hi Gary,
May I offer a different perspective on this.
On Wed, 30 Aug 2023 at 18:56, Gary Gregory wrote:
> - I like a mon-repo in general because:
> -- Everything is released together with the same version. There is no
> mystery of what works with what, what we tested with what. See the bugs
> wi
Here are my thoughts:
- I like 2.x as it is now as a mono-repo.
- I like a mon-repo in general because:
-- Everything is released together with the same version. There is no
mystery of what works with what, what we tested with what. See the bugs
with Maven plugins mysteriously breaking as counter-e
17 matches
Mail list logo
