@rschmukler I don’t represent any of the Clojars folks but I will say that you pretty much never want to delete published versions unless you know no one is depending on them: removing them will break people’s builds which is bad.

Also, if you have already published libraries into a group you will be able to continue publishing new versions of those libraries into that group — you just can’t publish new libraries into it.

What I’ve done for things I used to publish under seancorfield is to double-publish under seancorfield and com.github.seancorfield while folks transition over to the new coordinates.

Tools like antq are already detecting group ID changes and showing updated versions of libraries that have moved under new groups, by the way.

One potential solution I was mulling over was the notion of a redirected group... Basically, what if a clojars user could link a non-verified group that they have control over to a verified group... Then clojars does 302 redirects on all packages to their new (verified) org coordinates.

Still thinking about the implications around 1) do maven resolvers handle 302 ubiquitously, and 2) what sorts of invalid states can you arrive in if you attempt to migrate to a verified org that already published something under the same name

My repos don’t document the old group IDs any more so new folks coming to those projects will see the new group ID (and latest version) and not know about the old group — unless they trip over it in some other project of course 😐

Or they use clojars for discovery...

Which, when I was starting out in clojure, I tried to do - this change however seems like another blow to discovery on clojars

Well, at least there they’ll see bright green VERIFIED GROUP tags if they search for the artifact and see it in multiple groups 🙂

https://clojars.org/search?q=fs

I'd argue you'd end up at the wrong fs following the green badge

That’s a heavily-forked example though — the definitive version isn’t even shown on that first page (it’s https://clojars.org/clj-commons/fs )

6th result for me

Oh yeah, just noticed that.

But I agree, I'm just trying to demonstrate

I just looked at teknql and you only have one non-snapshot lib and very few downloads so maybe you’ve worrying too much about your pool of users?

(no offense intended)

None taken

My concern is more for orgs like metosin which seemingly will now have to fragment their libraries onto clojars (with new libs appearing in a verified org) or migrate all users to the new coordinates, and leave users new to the clojars ecosystem wondering whether they want metosin/malli or fi.metosin/malli

Truly it doesn't impact me, other than I think clojars is one of the first things new (potential) users see when evaluating the clojure ecosystem, and so having a "wow there sure are a lot of forks, even official ones" reaction is something that I think is worth considering whether we can solve

Framework authors will face a similar question. Eg - what happens when luminus wants to release a new library - do they keep publishing updates to the non verified org, and then release new libraries to com.luminusweb/* when the time comes, or do they migrate now? This isn't supposed to come off as critical by the way, but I am curious what authors are doing on the whole, and if we as an ecosystem are following any guidelines on it.

I have some fairly widely-used libs under seancorfield and a few other non-verifiable groups and I’m double-publishing them all under their current group and com.github.seancorfield for “a while” until I think folks have had long enough to switch over and then I’ll just stop publishing to the old groups. Tools like antq will help guide people to use the new groups (I’m not sure what logic it uses but I probably ought to read its code so I can talk about it to other folks).

I think the Clojars folks announced this pretty widely in advance and asked for feedback — I know I provided quite a bit, but I don’t know how much other library maintainers provided.

I raised issues with Leiningen and Boot for their handling of templates. Leiningen’s latest version includes support for templates that use verified group names, following the approach I took earlier with clj-new. The Boot folks have not responded to the ticket I raised.

(and I think lein new template provides a warning if you use a non-verifiable group style name)

I think Clojars could do more in terms of sorting/filtering of results to “encourage” folks to use verified group artifacts where they are more up to date (maybe the logic in antq could be leveraged for that?).

Hi @rschmukler! I agree that there will be some confusion for projects that decide to transition to a new name or have new related projects that now need to be deployed to a different group, which is unfortunate. I think @seancorfield's suggestion of pushing to both names for a bit is a good one. We also are having an ongoing discussion about using maven's built-in relocation feature that could aid in discovery of the new names, both in the Clojars UI and in tooling (see https://github.com/clojars/clojars-web/issues/801).

@tcrawley thanks for pointing me toward the discussion! This is exactly what I was hoping to find!