Dunno @U8SFC8HLP, good question. Codeberg is new to me. We have explicit tests for github, gitlab, and sourcehut.

I’ll create an issue about this, just in case.

There’s a bit of discussion around it here: https://github.com/cljdoc/cljdoc/issues/31 I think the tag approach makes sense but maybe float a proposal there and get some feedback + code pointers there if you like?

Fair enough. I actually think that the git tag version is better as it doesn't rely on any specific branch naming scheme or that the default branch be the one that all releases are made to. But people've spoken about that at some length there, I don't have much to add.

That sounds great. I think one open question with the git tag might be: how does cljdoc know to rebuild documentation. When a git tag is added or changed cljdoc will rely on some sort of mechanism for that.

I'd just figure it'd only rebuild if you click the rebuild button

and as an author you'd know if you force push that tag to change it you need to go to the site and click it

Then we’ll need a well visible rebuild button…. which we can have but I’ve sort of avoided adding it because it might increase unnecessary/spam builds.

I mean it's already established in the "for library developers" documentation that you need to click there, I don't think it needs to be any more visible, since git tagging like this is only relevant to library authors anyway.

Like there's basically already support for moving tags and rebuilding documentation, the only actual problem with the existing implementation is that for source-based libraries you basically have to have two different tags, one of them in your pom for cljdoc to find, and one "real" one for you to note in your docs.

I didn’t realize it’s documented now! In that case I think I’m ok with that reasoning and just looking up a specific tag 👍

I'm just thinking that when you look at the tag in the pom you prefix it with cljdoc/ and check that tag first when you rebuild.

Feels like a step in the right direction!

Should I make note of this in the issue? I thought this was the same as what had been suggested before, but maybe that's not true and it needs documented.

Yeah, I think especially if you intend to start working on it maybe just briefly flag that and the approach you’ll follow

There we go, I wrote up my thoughts and posted them there.

Coolio, glad someone (other than just me! 🙂) is diving in!

As mentioned in github comment we did some thinking around this in https://github.com/cljdoc/cljdoc/issues/459 and I think it matches what you are proposing @U5NCUG8NR.

Yeah I was originally thinking of this idea as it related to source-based libs, or dual-release libs, and I think that yeah, looking at the issue there it aligns with what I was thinking of very well.

There is a small nuance that I dug out of of my tattered old brain. Cljdoc assumes that the sources in the jar are in sync with the sources on git. It provides links to the sources on scm (usually github) from the API docs. So if the sources on git change enough, those links might not be exactly right after a rebuild. It might be enough to simply mention this when updating to the docs.