New package: Coconots v1.0.0

[JuliaRegistrator]

• Registering package: Coconots
• Repository: https://github.com/manuhuth/Coconots.jl
• Created by: @manuhuth
• Version: v1.0.0
• Commit: 7ea6738e00f5478201690e8a777fe5c57f420068
• Git reference: HEAD
• Description: Likelihood-based methods for model fitting, assessment and prediction analysis of some convolution-closed count time series model are provided. The marginal distribution can be Poisson or Generalized Poisson. Regression effects can be modelled via time varying innovation rates.

[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]

Personally, I would consider the comment in the README

A detailed documentation is planned to be available soon.

to be at odds with registering as a v1.0.0 version. If you are following semantic versioning, a v1.0 promises a stable API, which must be well-specified so that you can track breaking and non-breaking changes, going forward.

Your intuition to start with v1.0.0-dev in #127447 was probably a good one. In my opinion, it would be totally fine to tag v0.1 when making a package public that's on it's way to being stable, as "pre-1.0". That then allows you to refine the API after people have had a chance to actually use it, and to further work on the documentation. Then, you can directly tag v1.0 in the near future. There's no requirement that a v1.0 version somehow has to be "breaking" with respect to the last v0.x release; it's fine to use the v1.0 label to designate the package as "stable" (at least in my opinion).

So, I would recommend either adding full documentation (and, ideally, also tests with coverage) before continuing with the v1.0 registration, or changing the version number to something pre-1.0. But it's up to you. The README is already in pretty good shape, so I can unblock if you want to keep going with v1.0.

[manuhuth]

Thanks a lot for your review and suggestion. Using v0.1 sounds like a good option. What is the preferred way of uploading the v0.1-labeled version?

[goerz]

You just change the version in your project (in Project.toml), and retrigger the registration the same way you triggered this one. With a change in version number, that will create a new registration PR, and we'll just close this PR in favor of the new one. Exactly the same process as for #127447

[goerz]

Closing in favor of #127577