New package: SGCRNAs v1.0.0

[JuliaRegistrator]

• Registering package: SGCRNAs
• Repository: https://github.com/C37H41N2O6/SGCRNAs
• Created by: @C37H41N2O6
• Version: v1.0.0
• Commit: 55f897952566fc074090236a8a879686baac9af3
• Git reference: HEAD

[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 which are not met ❌

• Repo URL does not end with /name.jl.git, where name is the package name

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. 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]

Could you make sure that the README includes a brief description of what the package does, to have some context? Also, I noticed that the links to the documentation currently do not work.

Without context, it’s hard to give more specific feedback, but the package naming guidelines generally frown upon “random-letter” acronyms as package names.

[C37H41N2O6]

@goerz
Thank you for your comment. I'm currently making revisions, including the points you mentioned.

[goerz]

You may also want to consider what the appropriate initial version number should be. If you are following semantic versioning, a version number of 1.0 would indicate that the API is "stable" and that you will track breaking and non-breaking changes according to what is documented to be the public API of the package. That generally requires full documentation and, ideally, reasonable test coverage, in order to really be able to track those breaking vs non-breaking changes. There's nothing to say that an initial registration shouldn't be at v1.0, if you feel that it is ready for to be labeled "stable". However, if you are still tweaking things, it maybe be better to start with, e.g., v0.1 and then switch to v1.0 when you feel the package is in good shape. There's no problem with moving from v0.x to v1.0, just to mark the API stable.