- write documentation for the API methods (and arguments, return values, and arguments to callbacks and their return values, if applicable) and show examples of usage
- follow semantic versioning (x.x.X for bug fixes, x.X.x for backwards-compatible changes, X.x.x for breaking changes)
- consider versioning documentation in addition to releases if your project can be used as mission critical software (e.g. if it's a framework). This can be as simple as creating a task that copies a snapshot of the docs to an archive
- maintain a change log
- make sure your release is on the master branch (not gh-pages) if you're publishing to component.github.io
- setup channels of communication for discussion and support (gitter.im, IRC, mailing list, etc)
There were some things I intentionally left out (how to write good code, documentation) because I figured those were out of scope of this post (I did try to reference them subtly with the line "the code is in a place where it’s ready to publish"). I also left out some of the things you mentioned (versioning documentation, changelog, channels of communication, SO tag) because I figured those might fall into a Part 2 type of post, where I'd say "Now that you have a first version of your library published, let's discuss how to maintain it."
I'll be honest with you, I had a little issue with the length of this post, so I was trying to balance how much to include or omit.
I really appreciate the feedback, and I'll keep those points in mind for a Part 2 post!
- write documentation for the API methods (and arguments, return values, and arguments to callbacks and their return values, if applicable) and show examples of usage
- follow semantic versioning (x.x.X for bug fixes, x.X.x for backwards-compatible changes, X.x.x for breaking changes)
- consider versioning documentation in addition to releases if your project can be used as mission critical software (e.g. if it's a framework). This can be as simple as creating a task that copies a snapshot of the docs to an archive
- maintain a change log
- make sure your release is on the master branch (not gh-pages) if you're publishing to component.github.io
- setup channels of communication for discussion and support (gitter.im, IRC, mailing list, etc)
- create a tag in StackOverflow.com