For reference, the full error that caused me to do this is...

Error: failed to create resource: Job.batch "helm-hub-monocular-sync-initial-APPUiO-1j3lm" is invalid: metadata.name: Invalid value: "helm-hub-monocular-sync-initial-APPUiO-1j3lm": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Four things came up on this I needed to come back around to.

1) Should we allow uppercase in names?

For this I wanted to look at what others are doing. Here are some examples:

• composer (PHP) treats foo and Foo as the same. See https://getcomposer.org/doc/04-schema.md#name. Any character can be used in their name including spaces.
• npm is different. It must be one lowercase word. See https://docs.npmjs.com/creating-a-package-json-file
• Gems (Ruby) are lowercase only. This one was hard to find as it's in the recommendations rather than the spec. See https://guides.rubygems.org/name-your-gem/
• Docker Hub requires lowercase. If you use an uppercase letter you get the message "Letters must be lowercase" on the org creation page.
• Homebrew isn't easy to figure out because they go back and forth on case. Sometimes it's lower, sometimes it's camel, etc. As far as I can tell, the effective name people type is lowercase. See https://docs.brew.sh/Formula-Cookbook
• Cargo (Rust) appears to allow upper and lowercase names. But, I didn't see any uppercase names in the registry. See https://doc.rust-lang.org/cargo/reference/manifest.html
• Swift (from Apple) allows uppercase letters in names. See https://developer.apple.com/documentation/swift_packages/creating_a_swift_package_with_xcode
• OneGet (Windows pkg mgr) supports uppercase in names. See https://www.powershellgallery.com/packages

One of the big problems is that many of these are flat systems without namespaces. Docker Hub and Composer are examples that namespace. One requires lowercase and the other treats upper and lowercase as the same.

Overall, there seems to be a tendency to do lowercase in practice. Without having to hit the shift key it's less typing, too.

The names are used for display purposes which nudges me to want to allow uppercase letters.

If we use both we'll need to look at how this affects sorting in lists. ASCII sorting puts all uppercase letters before lowercase letters. See http://www.asciitable.com/.

2) How do we handle the same name as uppercase and lowercase? Do we need to do that?

If we can have the name samsung and Samsung (one with uppercase and one with lowercase) we need a clear way to handle these. The conversion to automatically lower would create a collision.

I would suggest we follow the pattern used by Composer:

it's case insensitive (foo/bar and Foo/Bar are considered the same package)

In the hub manifest we should update the list to be in alpha order which will help with visually checking until we can put automation in place. Should monocular itself provide an error?

3) What about other characters in names?

Names will often have other letters in them. For example "Samsung SDS". We currently use the name directory in the name of the Kubernetes objects which puts limitations in place. See https://kubernetes.io/docs/concepts/overview/working-with-objects/names/. Should we document those limitations? If we allow uppercase letters for display purposes does it make sense to transform some common things in names, such as spaces? We would need more collision detection in that case.

4) What about i18n names?

Helm is huge in China. Places that use non-alpha characters do a lot of Kubernetes. How do we handle that? While I don't think we need to deal with this now, I wanted to plant the thought while talking about naming.

It sounds like we can avoid some issues by only allowing names to be lowercase. That said, we do have a lot more control, currently, over collisions due to the acceptance process for a new repository. Most of the other services you mentioned don't have an acceptance process to publish content.

What about i18n names?

Good question, I don't know what the best answer is right now. We would need a solution for this site-wide too, and will likely need to use an i18n framework. I'm also not sure how we can deal with translating chart content (e.g. chart names, READMEs, etc.)