I've done a couple releases in this project so far (a Log4j and Logging
Parent release), so it shouldn't be too hard. I'm thinking we need to copy
over the log4j-distribution stuff so we can create source and binary
assemblies for uploading to apache.org as well.
On 8 March 2017 at 11:55, Mikael
I have never made any Apache release before, so it's probably good if
someone more experienced does it the first time. So I would be grateful if
Matt could do it.
I can maybe do it the next time.
On Mar 8, 2017 5:43 PM, "Matt Sicker" wrote:
> If you don't have time to do it,
Yes. Scala should be released asap and the site manually modified to point to
it. We would then modify the log4j source to permanently point there.
Ralph
> On Mar 7, 2017, at 10:09 AM, Matt Sicker wrote:
>
> Ralph pointed out that we can't make a release of the main repo
Ralph pointed out that we can't make a release of the main repo without the
scala modules until there is a release of the scala modules on their own.
Otherwise, there'd be a regression in the main repo by removing modules
that were there before.
On 7 March 2017 at 10:54, Remko Popma
No objection from me to release log4j-scala.
Do you have a versioning scheme that lets log4j-scala and log4j upgrade
independently?
Sent from my iPhone
> On Mar 8, 2017, at 1:42, Mikael Ståldal wrote:
>
> Can we release log4j-scala now? Or to we have to wait for
Can we release log4j-scala now? Or to we have to wait for the next release
of main repo with Scala modules removed? Should we remove the Scala modules
from main repo now?
On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker wrote:
> The Scala language versions is already done the same
The Scala language versions is already done the same standard way everyone
implements Scala libraries (hence the strange naming scheme we already
have). I'd imagine that the versions can be completely decoupled by
specifying a minimum Log4j API version it requires (though should generally
be
I guess the idea is that releases of Log4j 2 and log4j-scala should be
independent in both ways, right?
I think I have coordination between log4j-scala and Scala language covered
already.
On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma wrote:
> Mikael, you probably need to
Mikael, you probably need to plan your versioning scheme to handle any
combination of the following:
* log4j 2 releases: do you want to do a release for the log4j-scala modules
every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once
they are decoupled, the log4j-scala
I would like to keep package and artifact names, and bump version to 11.0.
On Mar 1, 2017 4:04 PM, "Matt Sicker" wrote:
> If you change artifact ids, it's generally a good idea to change packages,
> too. I've had issues in the past with Feign for instance because they
>
If you change artifact ids, it's generally a good idea to change packages,
too. I've had issues in the past with Feign for instance because they
changed groupId/artifactId at one point but kept the same API, so I had two
copies on the classpath until I found out there was a duplicate and
excluded
You can do that, but that will probably confuse users too. I would suggest
changing the artifactId and then start at either 1.0 or 2.0.
Ralph
> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal wrote:
>
> OK, but then at least we have to start with a version > 2.8.
>
> On
OK, but then at least we have to start with a version > 2.8.
On Wed, Mar 1, 2017 at 1:33 PM, Apache wrote:
> I guarantee if you try to keep the same versioning you will regret it.
>
> Ralph
>
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal
>
I guarantee if you try to keep the same versioning you will regret it.
Ralph
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal wrote:
>
> I was under the impression that we were not ready to integrate the site from
> log4j-scala. That's why I considered the release of
I was under the impression that we were not ready to integrate the site
from log4j-scala. That's why I considered the release of log4j-scala as
delayed, since there is no point of releasing it if we cannot get the site
integrated.
But now when Ralph says he's ready to integrate the site, I guess
One issue we came across in practice is that Scala 2.12 requires Java 8,
but we don't want to require that for the entire build, so we separated the
repo. This also helps avoid making the main log4j repo from taking forever
to build and release which can help the RERO idea. Plus, these non-core
To be honest I still don't understand
* the vision of what we ultimately want to achieve
* how different repos fit into that vision
* what different websites we are planning to create to give users access to
these different modules
* what websites are going to be driven from which modules or
I'd be in favour of starting a new release train for the Log4j Scala APIs.
Not exactly sure which version to start from, though.
On 27 February 2017 at 18:35, Ralph Goers
wrote:
> If you use that excuse they will never get released as it creates a
> catch-22. If I
If you use that excuse they will never get released as it creates a catch-22.
If I release without them then we have a regression until they are released.
This is why you shouldn’t really be releasing them using the Log4j versions.
Change the artifactIds so they can start at 1.0, 2.0 or
Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder
to release from the log4j-scala repo when two of the three artifacts will
already exist.
On 27 February 2017 at 12:14, Ralph Goers
wrote:
> Why is the release of log4j-scala delayed?
>
>
Why is the release of log4j-scala delayed?
Ralph
> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal
> wrote:
>
> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
>
> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
>
I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release.
I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought
that it would be released as part of 2.8, otherwise I would have put it to
the main repo as well. But now releasing of the log4j-scala repo has been
Relative symlinks would work for that regardless of version. Option 1 it
is, then?
On 25 February 2017 at 00:22, Apache wrote:
> Note that the link in the log4j site can reference a symlink so that the
> log4j site never has to change when the Scala site is updated.
Note that the link in the log4j site can reference a symlink so that the log4j
site never has to change when the Scala site is updated.
Ralph
> On Feb 24, 2017, at 11:21 PM, Apache wrote:
>
> Option 2 makes no sense to me. I don’t plan on being the release manager
Option 2 makes no sense to me. I don’t plan on being the release manager for
log4j-scala. In order for me to implement option 2 I would have to include the
log4j-scala site into the log4j release process - as well as log4j-examples,
etc if they move out. That is just not doable. Deploying the
The site repository is laid out like this:
log4j/2.x/ -(symlink)-> log4j-2.8/
log4j/log4j-2.8/log4j-api/
...
log4j/2.x/log4j-api-scala_2.11/
Option 1 is to put it here instead:
log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty
ugly URL honestly)
There is a specific location in svn where the site pages have to be committed,
so I don’t really understand option 1.
Ralph
> On Feb 24, 2017, at 9:48 PM, Matt Sicker wrote:
>
> I see two ways of doing that, though:
>
> 1. Commit the Scala site in a separate directory
I see two ways of doing that, though:
1. Commit the Scala site in a separate directory similar to what I started
doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if
possible to keep links from breaking.
2. Commit the Scala site where it would go when creating the main
From my perspective that doesn’t matter. However, we would really need a Scala
site before we can modify the Log4j site, otherwise it will be a dead link.
All that really needs to happen is the Scala site needs to be checked in
adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link
It is cosmetic, but we'd also be adding the Scala 2.12 module.
On 24 February 2017 at 14:17, Apache wrote:
> I don’t have the numbers but I have a couple of issues that need fixes.
>
> The modules stuff doesn’t require a major version bump. It is mostly
> cosmetic.
>
I don’t have the numbers but I have a couple of issues that need fixes.
The modules stuff doesn’t require a major version bump. It is mostly cosmetic.
Ralph
> On Feb 24, 2017, at 12:41 PM, Gary Gregory wrote:
>
> I think we can do 2.8.1 with our current bug fixes.
I think we can do 2.8.1 with our current bug fixes. Moving modules around
feels like a 2.9 item to me but that's just me. I really like the idea of
making bug fixes available ASAP. The only issue I see that fixing now is
the null classloader issue for which we have a patch but it does not work
for
32 matches
Mail list logo