-
Notifications
You must be signed in to change notification settings - Fork 131
Maintenance status of this repository? #225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Doing #254 first, then this can go forward |
User-visible changes since 3.9.2:
The rest is just build changes and version bumps and such. This release was brought to you by 13 contributors, according to |
release job: https://travis-ci.com/github/lightbend/scala-logging/builds/216562258 and hmm, |
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. |
new release job: https://travis-ci.com/github/lightbend/scala-logging/builds/216566079 gah, 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. |
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:
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?). |
@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. |
LoggerTakingImplicit
mocking
I can publish a release. Easiest option. |
@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 |
Ok I've setup the environment variables. |
@analytically excellent! maybe it makes the most sense to land #227 first, then tag a release? |
@SethTisue sounds good to me |
#227 is merged. |
@analytically ready to attempt a release? |
@SethTisue yes |
@analytically okay -- any questions for me about how to do it? |
@SethTisue anything I need to do? |
@analytically yes, see my remarks above at #225 (comment) . if you push a tag (either via the GitHub web UI, or from the git command line, whichever you prefer; I like to use the GitHub web UI), sbt-ci-release should build and release it via Travis-CI https://github.com/olafurpg/sbt-ci-release/blob/main/readme.md has full details |
Strange, I can't seem to create a tag via the Web UI |
at https://github.com/lightbend/scala-logging/settings/access just now I upgraded you from "write" to "maintainer", maybe that will do it? I'm guessing |
at https://github.com/lightbend/scala-logging/releases there should be a "Draft a new release" button in the upper right |
… On Tue, Mar 16, 2021 at 4:17 PM Seth Tisue ***@***.***> wrote:
at https://github.com/lightbend/scala-logging/releases there should be a
"Draft a new release" button in the upper right
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#225 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB6DYRMC6VWRMZSXCBUDG3TD6ABXANCNFSM4PKTPOPQ>
.
|
It's building now at https://travis-ci.com/github/lightbend/scala-logging/builds/220285472 |
|
Just an oversight in #258, I guess |
@analytically I reviewed the diffs at #258 and I don't see anywhere where I removed something I shouldn't have. |
Note that it's actually the same error message we got back in February: #225 (comment) |
Hello, sorry to highjack this discussion but it's related to the original topic. It seems like this library is pretty much abandoned from the discussion ... does that mean there is not going to be a dotty (/scala3) release? Thanks |
@tomasherman good question. I've opened #269 about that specifically EDIT: oh, haha, I forgot it was actually done already. so yes, once we get publishing straightened out, Scala 3 support will be published alongside Scala 2. |
@analytically I have no idea what the problem is here 🤷 |
@SethTisue fixed it |
Ah, I see #270 now. You could push a v3.9.4 tag, or you could delete the existing v3.9.3 tag and then recreate it — either way should work for triggering publishing. |
Pushed ... |
2021-03-23 14:11:37.493Z info [SonatypeClient] repositoryReleased: id:comtypesafe-2822, target:releases - (SonatypeClient.scala:377) |
Looks like it worked! |
niiiiiice. as you probably know, the lag before the artifacts actually show up on Maven Central is unpredictable. monitoring https://repo1.maven.org/maven2/com/typesafe/scala-logging/scala-logging_2.13/3.9.3/ |
Yay, Scala 3 artifacts at https://repo1.maven.org/maven2/com/typesafe/scala-logging/scala-logging_3.0.0-RC1/3.9.3/ 🎉 |
@analytically I added release notes to https://github.com/lightbend/scala-logging/releases/tag/v3.9.3 |
Uh oh!
There was an error while loading. Please reload this page.
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!The text was updated successfully, but these errors were encountered: