Permalink
Browse files

remove v from intrenal version, and test that it always matches packa…

…ge version
  • Loading branch information...
1 parent 6c3fb06 commit 72464eb70a78d8dd912f21b5a41400aee618e930 @polotek polotek committed Sep 10, 2012
Showing with 4 additions and 2 deletions.
  1. +1 −1 src/libxmljs.h
  2. +3 −1 test/main.js
View
@@ -5,7 +5,7 @@
#include <v8.h>
#include <node.h>
-#define LIBXMLJS_VERSION "v0.6.1"
+#define LIBXMLJS_VERSION "0.6.1"
#define LIBXMLJS_ARGUMENT_TYPE_CHECK(arg, type, err) \
if (!arg->type()) { \
View
@@ -1,7 +1,9 @@
-var libxml = require('../index');
+var package = require('../package')
+ , libxml = require('../index');
module.exports.constants = function(assert) {
assert.ok(typeof libxml.version == 'string');
+ assert.equal(package.version, libxml.version);
assert.ok(typeof libxml.libxml_version == 'string');
assert.ok(typeof libxml.libxml_parser_version == 'string');
assert.ok(typeof libxml.libxml_debug_enabled == 'boolean');

3 comments on commit 72464eb

Collaborator

defunctzombie replied Sep 10, 2012

Is there a reason to keep this field around? Would love to hear about actual places this is being used (not the hypotheticals :)

Collaborator

polotek replied Sep 11, 2012

Don't ask me. It was @ggd543 who filed the bug. I don't have any concrete reasons. I do think having the libxml2 version used to build against is handy if you're trying to track down issues. And with that, it makes sense that you want to know libxml2 version + the module version. That gives you the full story of what you're running. It doesn't hurt to leave it in. Would be nice to be able to set this internal var based on the package.json instead of having to keep them in sync. Can we have the build do that?

Collaborator

defunctzombie replied Sep 11, 2012

Lets see what he says about it. I think a better approach if you want the version info for the actual package in your code would be to use the npm module to get it (I think this is possible). That way you would be able to do it for any package you cared to do this for and would not require the module authors to make this available everywhere since it is already available in the package.json. Given the npm approach I would be in favor of removing the module version from the code but keeping the libxmljs version (although I too have doubts about the benefit of that :/)

Please sign in to comment.