Maintenance status of this repository?

It looks like the latest version, 3.9.2, was published in Jun, 2019. I'm wanting this fix made in Aug, 2019 so I can mock LoggerTakingImplicit in tests. When is the next release planned? I'm happy to help if I can. Thanks!

[SethTisue]

Doing #254 first, then this can go forward

[SethTisue]

User-visible changes since 3.9.2:

• Fix for shapeless @@ types passed on as args (Fix for shapeless @@ types passed on as args #219)
• Improve testability of CanLog by making LoggerTakingImplicit no longer final (Improve testability of CanLog by making LoggerTakingImplicit no longer final (helps fix #40) #181)

The rest is just build changes and version bumps and such.

This release was brought to you by 13 contributors, according to git shortlog -sn --no-merges HEAD ^v3.9.2. Thank you Scala Steward, Seth Tisue, Philippus Baalman, sullis, Adriaan Moors, Francis De Brabandere, Eric Meisel, Dejan Stojadinović, Bruno Bonanno, Ty Coghlan, Kenji Yoshida, mwielocha, Krzysiek Bochenek.

[SethTisue]

release job: https://travis-ci.com/github/lightbend/scala-logging/builds/216562258

and hmm, 2021-02-09 17:05:09.894Z error [Sonatype] [MISSING_PROFILE] Profile com.typesafe.scala-logging is not found. Check your sonatypeProfileName setting in build.sbt - (Sonatype.scala:405)

[SethTisue]

I might be able to get the rights to publish to that org, but I think this is an opportune time to change Typesafe to Lightbend everywhere. I will also bump the version to 4.0.0.

[SethTisue]

new release job: https://travis-ci.com/github/lightbend/scala-logging/builds/216566079

gah, 2021-02-09 17:36:20.845Z error [Sonatype] [MISSING_PROFILE] Profile com.lightbend is not found. Check your sonatypeProfileName setting in build.sbt - (Sonatype.scala:405)

I thought my Sonatype account had permissions to publish to com.lightbend, but I guess not. (I have them on Bintray, maybe got that confused in my head?)

Oh, it seems from https://issues.sonatype.org/browse/OSSRH-49971 that I have com.typesafe rights but not com.lightbend rights. But I guess the com.typesafe rights don't apply to com.typesafe.scalalogging? Regardless, I should get com.lightbend rights.

I think we should go forward with the renamings regardless.

I've made a query inside Lightbend about getting rights.

[SethTisue]

I think we should go forward with the renamings regardless.

After discussing this with Adriaan, he convinced me we shouldn't do that, actually. And I have now reverted #259.

The issue is that there is a tendency for Lightbend customers -- and others! -- to assume that anything that says "lightbend" is supported by the company. Both in the sense of commercially supported and in other, more informal senses of "supported". (There is a notice about that in the readme now, but people make assumptions regardless.)

When people assume that, it has two downsides:

1. Users may be upset or disappointed.
2. New maintainers will be discouraged from stepping forward, if they think that Lightbend is already taking care of it.

But this library is now almost entirely community-maintained; no one from Lightbend is volunteering to play more than a minimal role here.

Ideally, there would be some sort of orphanage or halfway house that could be a home for libraries like this, where the original maintainers are no longer interested. I'm only vaguely aware of what exists in this space (https://adoptoposs.org?).

[SethTisue]

@analytically Can I ask you how interested you are in this library?

Option 1: You could assume ownership entirely (under your personal account or under some other org), and cut all ties with Lightbend/Typesafe in the naming and publishing. We could transfer this repo to your ownership, or we could archive it and you could fire up an entirely new repo, which we'd link to.

Option 2a: We could leave the repo where it is, but you would assume responsibility for releases and publishing. Adriaan thinks you may already have the needed permissions on Sonatype; do you know if that's the case? Now that my sbt-ci-release PR is merged, all it takes to publish releases is for someone with the right Sonatype permissions to set the secure environment variables at https://travis-ci.com/github/lightbend/scala-logging/settings appropriately, following the instructions in the sbt-ci-release readme. And once they're set, publishing is as simple as using the GitHub web UI to create a tag+release.

Option 2b: We could leave the repo where it is, and I would acquire publishing permissions to com.typesafe.scalalogging and take over pulling release levers as needed.

Thoughts? I'm willing to do 2b if necessary, but my level of participation would remain quite minimal.
1 or 2a makes more sense if you're interested in actually seeing this library be healthy and not just straggle along on life support.

cc @adriaanm
cc @amumurst

[analytically]

I can publish a release. Easiest option.

[SethTisue]

@analytically awesome! in that case we would prefer to leave everything under com.typesafe. this will minimize disruption for users, and it's also something of a signal (admittedly only a weak signal) that the library isn't being actively maintained by Lightbend.

have you used sbt-ci-release before? in order to do tag-based publishing, now that #254 is merged, you'll need to go to https://travis-ci.com/github/lightbend/scala-logging/settings and add PGP_PASSPHRASE, PGP_SECRET, SONATYPE_PASSWORD, and SONATYPE_USERNAME to the Environment Variables section, as per the instructions at https://github.com/olafurpg/sbt-ci-release/blob/master/readme.md . once that's set up, doing a release is as easy as pushing a tag (either from the command line, or via the GitHub web UI at https://github.com/lightbend/scala-logging/releases/new)