Anyone here have context on https://github.com/adambard/failjure? Last commit 2023-04-29, 15 open issues, ~4yr stale correctness bug (#31). @adambard still GH-active in general but seems to have stepped away from this one specifically. Several of us depend on it in production. Opened https://github.com/adambard/failjure/issues/41 to discuss upstream — wondering if clj-commons would consider receiving a transfer?
got https://github.com/adambard/failjure/issues/41#issuecomment-4937601899 from library owner. how do I initial the transfer process?
The owner—or someone with admin privs—of the failjure repo would need to initiate the transfer. We'd have to give them write access to the clj-commons org first, I believe, so we'd need to know the GH username.
https://github.com/adambard is the owner, who also gave the https://github.com/adambard/failjure/issues/41#issuecomment-4937601899.
I can also volunteer to be a maintainer since we use it at work, if this makes it easier.
@gzmask I sent Adam an invite to clj-commons, so he can initiate the transfer. What's your GH and I'll invite you?
thanks! my handle is https://github.com/gzmask
Okay, you should get an invite too.
And "Thank you!" for volunteering to (help) maintain it going forward.
Can you also ask Adam if he's willing to open up the failjure group on Clojars so we can continue publishing artifacts under the same group ID?
He could add me as a group admin <mailto:sean@corfield.org|sean@corfield.org> or seancorfield and I can then manage whatever is needed by clj-commons for automated releases from CI.
(otherwise, we'll switch to publishing it under the clj-commons group, but that breaks continuing for users when upgrading, and would require all the nses to change as well to avoid conflicts if two different versions end up on the classpath)
that make sense, so downstream users don't need to update their clojar url. I will ask in the issue.
Thank you!
Everything is updated—but GitHub Actions is "down" right now, so no workflows are triggering...
Once that's working, every commit to master will trigger a new SNAPSHOT to Clojars, and cutting a release on GitHub itself will automatically trigger a build & deploy to Clojars for that full release. It will automatically use MAJOR.MINOR.COMMITS for the version number, but I can change that to regular version numbers if you'd prefer.
I like COMMITS but it's a bit of a PITA when you're cutting a release since you to have check how many commits you have and know that updating the README/CHANGELOG etc will be one more commit.
Let me know if you have any Qs about the way I have it set up...
i don't like commits for all those reasons. i like major.minor.oops, where the final one is when you mess up a release (one time i released an empty jar because i didn't have my build.clj right lol) or there's some terrible bug, or a show-stopper etc
That's a new one for me! major.minor.oops! simple_smile
hah that's just how i think about it. "patch" doesn't quite convey how it feels to cut a release, and then immediately experience a problem and cut a new one to solve it lol
GitHub Actions is recovering. One of the commits I made led to a new 2.3.99-SNAPSHOT being deployed to Clojars so the automation works, in case @gzmask you feel like testing against that, just to make sure the JAR is good etc. I haven't used failjure before so... :)
Happy to help work through the issues and PRs. Some of those have merge conflicts now—I renamed test_core.cljc to core_test.cljc which is more idiomatic (and what test runners generally expect). I renamed README.markdown to README.md as well, BTW.
wow, thanks for setting up all the release publish pipelines! I will give this a test later today, and see if I can help with some of the issues/PRs!