-
Notifications
You must be signed in to change notification settings - Fork 461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
automatic merging guidelines #3673
Comments
? Many packages do not follow this, e.g. HTTP. |
A package with a name like HTTP would require review. |
Is that to catch non-obvious acronyms or something? |
Yes, or people who just capitalize an entire package name for no reason, e.g. MYPACAKGE.jl. |
This may go without saying but: We should also check every pull request to make sure that it only modifies files related to the package it claims to be related to. For example, a pull request to register a new package Otherwise, we would have a security vulnerability:
|
We would only automerge PRs made by Registrator, which we control, not PRs made by people—those must be manually reviewed. |
Perfect! |
I have opened a pull request that implements these automatic merging guidelines: #3342 |
I would like to suggest ammending this to:
Basically, if you didn't touch a dep or its compat, then you should still get auto-merge. For example lets say my package depends on DataFrames.jl, So I only lower-bound it, because I am pretty confidant that DataFrames is not going to stop exporting that type. Now later I update my package, I haven't changed how I use DataFrames, But If later I do bump my minimum DataFrames compat, then I should be stopped since my past evidence has been proven wrong, and I do need the upper-bounds. |
Personally, I would like to keep the automerging guidelines as conservative as possible. The goal (at least as I envision it) is not to automerge every package, but rather to automerge many packages. The use case that you describe is totally fine, but I think it’s okay to have those PR’s be manually merged. |
@oxinabox The other thing we can do in your specific use case is set the compat for DataFrames to something like |
Manually merged the first time. It is fine for packages on slow release cycles,
That is not a legal compat specifier, AFAIK. Could say: |
It will be at some point. See JuliaLang/Pkg.jl#1232 |
Things I need for JLL package merging to be automatic:
My PRs currently come in under |
We can hardcode some exceptions for JLL packages. That being said, I would prefer that we first figure out the automerging for regular packages, get that merged, and make sure it works in production. Once automerging for regular packages has been deployed in production for a while, and we have fixed all of the bugs, then we can open a separate issue for automerging JLL packages? Does that sound like an okay plan? |
Also, to make life a little easier, would it be possible for you to use the same title format as Registrator for your pull request? For example, Registrator pull request titles look like this:
Could you change the format of your titles to look like this:
Do you think that would be possible? It would make my life much easier when I start working on automerging for JLL packages? |
Yes; is it strictly necessary to disambiguate |
Presumably we will keep the existing requirement that new packages have a 3 day waiting period. |
@staticfloat I opened an issue specifically dedicated to the automerging of JLL packages: JuliaRegistries/RegistryCI.jl#6 |
@StefanKarpinski @fredrikekre What do you think about closing this issue? Further issues regarding automerge can go here: https://github.com/JuliaRegistries/GeneralRegistryCI.jl/issues |
Copied from JuliaRegistries/General#3673 with minor formatting changes (a bit more compact), added clarifications for all questions which came up in the related discussion https://discourse.julialang.org/t/announcement-automatic-merging-for-the-general-registry/29961
These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.
New package
r"^[A-Z]\w*[a-z][0-9]?$"
0.0.1
,0.1.0
,1.0.0
/$name.jl.git
wherename
is the package nameNew version
1.2.3
then the next can be1.2.4
,1.3.0
or2.0.0
[deps]
should also have[compat]
entries (and Julia itself)[compat]
entries should have upper boundsThe text was updated successfully, but these errors were encountered: