On both cases, only package word as package name should be fed to the compiler. The org part is purely for registry purposes and the resolver will reject the following manifest with duplicated package conflict error:
Reason: Support publishing forks to the registry. Suppose package company/X has a critical bug, but the maintainer is not responsive. Community can create a fix, push it to a fork and publish this it as community/X. Users will only have to change their manifests, instead of having to also rename all references to X in their codebases.
Note: I would rather avoid Javaesque/Apple domain-styled organization names (i.e. prefer starkware instead of co.starkware etc.) and in order to enforce this I plan to ban names like x.y.z
On both cases, only package word as package name should be fed to the compiler. The org part is purely for registry purposes and the resolver will reject the following manifest with duplicated package conflict error:
Reason: Support publishing forks to the registry. Suppose package
company/X
has a critical bug, but the maintainer is not responsive. Community can create a fix, push it to a fork and publish this it ascommunity/X
. Users will only have to change their manifests, instead of having to also rename all references toX
in their codebases.Note: I would rather avoid Javaesque/Apple domain-styled organization names (i.e. prefer starkware instead of co.starkware etc.) and in order to enforce this I plan to ban names like x.y.z