Hello package maintainers (and everyone else too 
)! We have some new RegistryCI features that we hope will help make registering packages smoother.
Background: what is RegistryCI? And what is “the General registry”?
The General registry is a repository of open source Julia packages. It is installed by default, and it is where packages come from by default when you do ] add MyPackage.
RegistryCI is the Julia package that powers the automatic merging of registration requests for the General registry. (It can also be used on your own registries!). This is what writes the “AutoMerge comment” that says if your new package or new version will get merged automatically, or if some guidelines were not fulfilled.
New feature 1: Some AutoMerge checks can be skipped if the author wishes
When you register a new version of your package, one of the checks AutoMerge does is a “sequential version check”, to see if a version has been skipped. For example, registering v1.1 and then v1.3 skips version v1.2. This isn’t a big problem, but it often happens by mistake, so we prevent auto-merging the pull request so the package author has a chance to fix it if they want to.
Previously, package authors could request manual intervention to merge the pull request anyway, if they had some reason for skipping the version. Now however, that intervention has been automated: the package author can comment [merge approved], and a label will automatically be applied to the PR instructing AutoMerge that the author has approved of merging anyway. AutoMerge will re-run, see the new label, and skip the sequential version check.
Currently, the sequential version check is the only check that can be skipped in this way. In the future, however, we may use this new framework to add other optional checks. For example, if a breaking release of a package would break a large amount of downstream dependencies, we may ask for confirmation from the author before registering the version, in the future.
New feature 2: The name similarity check can be overridden
If a package’s name is “too similar” to another registered package’s name, AutoMerge is blocked. This check exists primarily to prevent “typosquatting”, where a malicious package is registered with a very similar name to a popular package. It also helps prevent ordinary confusion, since having two packages with very similar names can be a bad experience for users.
However, this check can be overzealous, and ends up blocking many new packages. Previously, a registry maintainer would add a label indicating the name was OK, and then after the standard 3 day waiting period for new packages expired, manually merge the package. However, such PRs were often left dangling for some time.
Now, the label Override AutoMerge: name similarity is okay is in fact respected by AutoMerge, and when that label is applied, it will re-run and skip the name similarity check. Thus, the package will be automatically merged once the waiting period is up, assuming all the other checks pass.
This allows anyone with triage-level access to General to help merge such package registrations by applying that label.
New triagers!
We are excited to welcome @Lilith, @GunnarFarneback, and @goerz to the General registry maintenance team. They have all already contributed to General by helping folks out with their registrations. Now they are additionally empowered to add labels such as Override AutoMerge: name similarity is okay and close old PRs.
As volunteers, they (and the rest of General’s maintainers) may have limited time and varying availability; if you have an issue with a package registration you are encouraged to post here on Discourse or in the #pkg-registration channel on the public Julia Slack for help, rather than tagging any specific maintainer.
And remember that anyone can help maintain General!
Other improvements
We renamed the “checks” that appear at the bottom of each PR, so they appear as "Registry Consistency” and “AutoMerge” (instead of “CI” and “AutoMerge”). Note that all such checks must pass for a registration to be automatically merged.
Oh, what happened to the stdlib compat thing?
We began requiring compatibility bounds for standard libraries, just like they are required for regular packages. This is because there are plans for standard libraries to be upgradable instead of tied to a specific Julia version.
However, doing so revealed a latent Pkg.jl bug in which Pkg had trouble resolving test environments in some situations in which packages had compatibility bounds on standard libraries. While there is a workaround (allow <0.0.1 in the bounds), we decided to turn off the requirement for packages to have compat bounds for stdlibs again, while this was sorted out.
This bug has been fixed on Julia 1.9 and later, but the fix has not been backported to Julia 1.6 yet. We will likely soon re-enable the requirement for packages which are declared compatible only with Julia 1.9 or later, which don’t support earlier Julia versions anyway. We hope to eventually be able to re-enable the requirement across the board, as compatibility bounds are essential for the package ecosystem to function well, and at scale.
By the way: contribute to RegistryCI.jl!
RegistryCI.jl is a Julia package that runs in General’s CI to power AutoMerge. Contributions to RegistryCI can have a big impact across the ecosystem, but RegistryCI does not get much attention. I think part of the reason why is the whole thing seems somewhat mysterious. So let me take the opportunity to make a sales pitch for contributions to RegistryCI and try to explain a bit more about how it works.
AutoMerge works by checking the package against a sequence of guidelines. These can be very simple to write. For example, there is a guideline that the package name should be composed only of ASCII characters. The implementation is only 9 lines long, and it is integrated into the list of guidelines that are checked for each new package registration with one line.
These don’t have to be quite so simple though! We download the package code, so we can look inside to find a license, using other Julia packages to help. And for new package registrations, we even often solve hundreds of optimization problems to compute the “visual distance” (using optimal transport) between images of the name of the package and existing package names. That one typically doesn’t end up being very useful with our current tunings though (usually our Damerau–Levenshtein distance check triggers first, so the visual distance doesn’t come into play).
The point being, we have the full power of Julia and the package ecosystem available within RegistryCI, and there’s a lot of flexibility to the system. So there’s a lot we can do here! Please, check out the repo, check out the open issues, and think about what you’d love to have in our AutoMerge system. It may be simpler than you think to implement!