3 ms·
A couple of other things I do w/ Mithril.js ( http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/ ) - write documentation for the API methods (an
by lhorie 12y ago
A couple of other things I do w/ Mithril.js ( http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/ )
- 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
- benmanbs 12y agoThanks so much for the read! 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!
- lhorie 12y agoIt was a good post, I wasn't trying to criticize it, just wanted to add to it based on my own experience :) Looking forward to a part 2!