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
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