Version number in trunk should be other then latest release about solr-node-client HOT 4 CLOSED

Hello @scherler,

Why do you want to change the version number? I don't understand

I try to follow semver conventions http://semver.org/.
Well at the moment that's quite easy, when the major version is with 0, it means that the API is not stable and that anything can change but I won't do that.
If something is removed in the API, I will bump the minor version number. If we add some new stuff do the API without breaking backward compatibility I will bump the patch version number. My plan is to support Solr 4 interface in solr-client 0.3.x, when this new version will be tested in production and review my other contributors I will bump the version to 1.0.0, which will be the first stable regarding semver. At this stage I will respect semver conventions without exceptions. :)

from solr-node-client.

The current number is the same as the published one in npm.

I am Apache member and in all projects I had the pleasure to participate the released version is not the same of the current HEAD of development. ...but that is not true, since e.g. ATM the facet feature is not in the published lib but in HEAD but both have the same version number which is not logical. Head should be the "unreleased" next version of the product.

Point is: current HEAD version > current release version

from solr-node-client.

Ì see what you mean, but it is common pattern in the node.js community to update the version in the package.json when doing a release and publishing on npm, between two version we don't change the version number, only on the next release. Each version that appear in the package.json are published on npm. If you like to use feature a in master not yet released and so unavailable on npm, you can directly point to the git repo when you declare your dependencies in the package.json. It would be something like this:

{
 "dependencies" : {
 "module-name" : "git://github.com/user/project.git#commit-ish"
}
}

You can learn more stuff about it in the dependencies section on this page https://npmjs.org/doc/files/package.json.html.

Anyway that may be a good practice to make thing clearer, thanks for the suggestion, I will probably apply it after the next release.

from solr-node-client.

I think I may close this, thanks for the comment @scherler.

from solr-node-client.