Fork me on GitHub
Ben Sless08:01:52

What's the rationale behind stripping scm from the top key by default but leaving other reverse DNS paths?


@ben.sless For GitHub projects in general, folks don't typically follow the full reverse-DNS structural naming, and when initial versions of the *new tools did that, people complained. For more "corporate" projects, people seem far happier to follow the full reverse-DNS structural naming. On top of that, having (io|com).(github|gitlab) in the structural naming really adds very little -- although you may get collisions between GitHub and Gitlab that's not very likely and you can't get collisions between usernames on GH so the prefix is entirely superfluous there. It's also somewhat likely that user foobar on GH and GL are the same person, so having their projects arbitrarily structured based on which service they host their code on seems... unnecessary... and I know a few people who've started moving projects from GH to GL and they would want to keep the same naming structure across the two services.


Anyone who creates a new project targeted for GH/GL is welcome to structure namespaces and choose a project group ID that reflects the hosting service if they want, of course, but my experience is that most people don't want to.

Ben Sless18:01:58

Makes sense, thanks


TL;DR: pragmatism 🙂