Well, that's a decision we have to make. So far, logging-log4j-plugins
has not been released yet, so we are now free do decide how to do it.
I guess that logging-log4j-plugins over time will contain a diverse set
of appenders, layouts and other plugins for Log4j 2, each one in its own
Maven module. Those plugins will normally not be releated to each other.
I can see some advantages, and some disadvantages, with versioning and
releasing plugins independently from core.
But to gain those advantages, each plugin should have it's own version
and release schedule. To have one version/release for all plugins (but
different from core) does not make sense to me, it will give us all
disadvantages, but few of the advantages.
When thinking about it, it's probably not even a good idea to have
a logging-log4j-plugins repository in the first place. Instead we should
create a new repository for each new plugin. And have a way to quickly
bootstrap such reposisory with needed boilerplate, maybe with a Maven
archetype.
And since we haven't started using the logging-log4j-plugins repository
yet, we have the oppourtunity to do it differently.
On 2018-01-17 00:34, Ralph Goers wrote:
Because logging-log4j-plugins is released separately from logging-log4j2 and
the versions would not line up.
Ralph
On Jan 16, 2018, at 2:31 PM, Mikael Ståldal <[email protected]> wrote:
Why do we need to change the version number?
On 2018-01-14 22:11, Ralph Goers wrote:
I don’t believe the components listed in the subject line should be part of the
main flume build and would like to see them moved to the logging-log4j-plugins
project. The only problem is that the modules and maven coordinates need to
change since the version numbers will be going backwards. I would propose we
solve that by adding “plugin” to the jar names.
