Interesting note: the SemVer spec says breaking changes only refers to the public API. But a core contributor clarifies that breaking changes can come from changes to the public contract that you intend users to depend on. See this GitHub thread.
Minimize dependencies in your package to make it easier for users to manage their dependencies
"Vendoring" elm packages (using a local copy instead of doing elm install author/package-name) can be useful in some cases to remove a dependency from your package
Should you publish a package?
The Elm package ecosystem has a high signal to noise ratio
Elm packages always start at version 1.0.0
SemVer has different semantics before 1.0.0 (patch releases can be breaking before 1) - see SemVer spec item 4
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Elm package philosophy is to do an alpha phase before publishing package
Keep yourself honest about solving meaningful problems
Start by asking "What problem are you solving? Who are you solving it for?"
Dillon's elm-publish-action GitHub Action will publish package versions when you increment the version in your elm.json - nice because it runs CI checks before finalizing a new package release
elm publish will walk you through the steps you need before publishing the first version of your Elm package
#packages channel on the Elm slack shows a feed of packages as they're published
#api-design channel on the Elm slack is a good place to ask for feedback on your API design and package idea