New package: AutoHist v1.0.1

[JuliaRegistrator]

• Registering package: AutoHist
• Repository: https://github.com/oskarhs/AutoHist.jl
• Created by: @oskarhs
• Version: v1.0.1
• Commit: 751b1764f6e583f1c8ae04d0f509f132779894ba
• Reviewed by: @oskarhs
• Reference: oskarhs/AutoHist.jl@751b176#commitcomment-156996980

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

From the README:

A detailed description of the supported methods will be added at a later point in time.

If you are following semantic versioning, that would be at odds with an initial version number >= 1.0. As a general rule, versions <v1.0 are for initial development, when the API of the package isn't nailed down yet, the package does not have a lot of dependents, and "backwards compatibility" is not a major concern. For an initial registration, that's usually the situation your package is in. Thus, an initial v0.1 is usually the way to go. The bar for registering an initial v0.1 is not very high. Basically, just

• Must have a name that is appropriate for the scope of the package
• Must have some non-trivial functionality (no "placeholder" packages)
• Must have a README that explains the purpose of the package and gives a basic usage example (or a link to documentation that is sufficient to figure out how to get started)

For a version v1.0, you're saying that the package already has a stable API. That has some implications for what one would expect from that package. Personally, I tend to apply the following guidelines:

• Must define the stable API. That generally means complete documentation.
• Should have tests with reasonable coverage (on the order of 80%). Otherwise, there's no way to know if the package actually implements its API correctly, and no basis for figuring out whether a pull request is "breaking" or not, going forward.
• Should somewhat reasonably fill the described scope of the package. No major gaps in functionality.

Even if you think your package is fairly polished already, I always recommend registering with an initial v0.1 anyway. That way, you have a chance to find out whether there are any major flaws in the package once people start to use it. Once it has a few dependents and you really should start to worry about maintaining backwards compatibility, you can always make a v1.0 release. That doesn't mean you absolutely have to make significant changes to the v0.1 version. Just make sure that your package is fully documented as "stable" at that point, has good test coverage, and all the other things people would expect from a "stable" package.

Ultimately this is your decision. If you want to lower the version number, you can just do another registration. You can also add a full API documentation while the registration is still pending, and then just retrigger the v1.0.0 registration or the v1.0.1 registration here.

Retriggering a registration to fix issues found while the registration is pending normal; you should generally not change the version number to, e.g., v1.0.2 while a registration is pending (unless the version number is inappropriate, of course). Retriggering while keeping the version number the same updates and existing PR, changing the version number creates a new PR.