Strategy for versioning on a public repo

Posted by biril on Programmers See other posts from Programmers or by biril
Published on 2012-11-30T02:47:44Z Indexed on 2012/11/30 5:25 UTC
Read the original article Hit count: 264

Filed under:
|
|

Suppose I'm developing a (javascript) library which is hosted on a public repo (e.g. github). My aim in terms of how version numbers are assigned and incremented is to follow the guidelines of semantic versioning.

Now, there's a number of files in my project which compose the actual lib and a number of files that 'support it', the latter being docs, a test suite, etc. My perspective this far has been that version numbers should only apply to the actual lib - not the project as a whole - since the lib alone is 'the unit' that defines the public API.

However I'm not satisfied with this approach as, for example, a fix in the test suite constitutes an 'improvement' in my project, which will not be reflected in the version number (or the docs which contain a reference to it). On a more practical level, various tools, such as package managers, may (understandably) not play along with this strategy. For example, when trying to publish a change which is not reflected in the version number, npm publish fails with the suggestion "Bump the 'version' field set the --force flag, or npm unpublish".

Am I doing it wrong?

© Programmers or respective owner

Related posts about version-control

Related posts about git