Name does not meet guidelines (too short, too similar). However, per the Julia naming conventions I would like to keep the name as is (TauP) because this package is a wrapper to a well-known Java program in the seismic community of the same name.
Problem with [compat] entry for dependent packages. Any advice on how to define these would be appreciated. Simply defining something like, PkgA = “0 - 1”, does not seem to resolve the issue.
The name seems ok to me, since it’s a wrapper (but I don’t have merge permissions, so it’s not up to me)
Problem with [compat] entry for dependent packages. Any advice on how to define these would be appreciated
You should explicitly list all 0.x versions of your dependencies that you support. But, do you have a CI step that tests that your package actually runs with the very first 0.1 release of all of your dependencies, as well as all the latest releases? Since all 0.x releases are breaking, you’re probably overpromising: I’d be very surprised if you’re actually compatible with all 0.x and all 1.x versions of all your dependencies.
In your case, I was just suggesting that your stated compatibilities are unusually broad, so you should actually verify them (at least manually, if not by CI).
What most people do, and what is probably the right solution for you as well: When you’re registering your new package, set the compat entry for all of your dependencies to the x.y that is the most recent release for that dependency. This means that your package will require that dependency version as a minimum, and also accept any future releases of the dependency that are not breaking according to semantic versioning (so all 0.y.* versions and all x.*.* version for x > 0).
When you make new releases of your packages in the future, verify that the compat entry for all your dependencies is still ok (that is, your package still works with the given minimum version). If not, update the compat entries to the most current release of your dependency.
Thanks for your response. Initially, I was being lazy in trying to define the compatibilities by making them so broad. I’ve since defined them based on the versions used in developing the package and this has fixed the issue.
Name problem persists but I’ve requested help in the slack #pkg-registration channel as directed by the github-actions bot.
@mkitti Thanks! I had read the linked documentation for compat prior to adding this in my Project.toml (and indeed it was not always intuitive) but I wasn’t aware of this package. Thanks for the infos.