New package: FlatMat v1.0.0-DEV

[JuliaRegistrator]

• Registering package: FlatMat
• Repository: https://github.com/thomasc791/FlatMat.jl
• Created by: @thomasc791
• Version: v1.0.0-DEV
• Commit: 2b0b9ec875493f235eb2f57b59ba8fc2b52327b7
• Git reference: HEAD
• Description: Contiguous vector of vectors in Julia

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

• Version number is not allowed to contain prerelease data

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]

Thank you for submitting your package! Could you add a little bit of documentation before registering? At the very least, that would be a description of the package's purpose and a small usage example in the README. An important part of packages in General is that any potential user can figure out what the package is about and how to get started with using it. That is really difficult when there is no documentation.

As an related issue: are you sure you want to register with an initial version v1.0? In the Julia ecosystem, we try to encourage the proper use of semantic versioning. 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 documentated as "stable" at that point, has good test coverage, and all the other things people would expect from a "stable" package.