Remove datapackage_version #140

Closed
rufuspollock opened this Issue Sep 20, 2014 · 3 comments

Projects

None yet

3 participants

@rufuspollock
Contributor

Proposing to remove:

  • Already a SHOULD which makes it less than useful as something always reliable
  • I never add it in the work I do
  • What is it needed for? (normal logic is being able to work out when there is a major breaking change but we can then introduce this when we need it e.g. v2.0 ...)
  • commonjs spec does not have this (nor do many other packaging specs)

Note existing discussion in #122

@trickvi
Contributor
trickvi commented Sep 20, 2014

I don't agree, but I might be alone. I find that all of these changes which are just (if I understand how the versioning system works) patch versions to be pretty big changes (some even backwards incompatible like renaming stuff:

  • 1.0-beta.10: license introduced and licenses updated as per this issue
  • 1.0-beta.8: last_modified and modified removed following this issue
  • 1.0-beta.7: dependencies renamed to dataDependencies following this issue
  • 1.0-beta.5 -> 1.0-beta.6: Moved resources from MUST to MAY

At least knowing what version a data package is, is very helpful for those who build data package parsers. My vote would be to go the other way and make this a MUST (but I'm also willing to accept that I might be the only one who is dumb enough to rely on versioning of often times hand-made descriptor files).

@rufuspollock
Contributor

To be clear: I agree this could be useful. The issue is will anyone observe it? I haven't added it for a single one of the data packages i've created. Sure tooling could add it but none does afaik and you'd have to worry about tool having wrong version. Finally, would anything consuming actually know or care (at least atm).

So my point is not that this couldn't be useful but that it is unlikely to, at least for quite some time and I'd prefer not to have stuff in the spec that we don't actually observe - this is a general principle of spec stuff that "its easy to want things and hard to have them"

@rufuspollock
Contributor

I'm going to implement this - i.e. remove the field. It is not required, it is only vague used, i think it is probably unreliable so little us to consumers etc. My guess is that if you really care you'll probably do some datapackage.json inspection to try and guess what is happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment