Version the spec itself

[cvrebert]

The spec itself ought to be versioned, and a field should be added to bower.json indicating at least the major (and perhaps also the minor) version of the bower.json spec that it claims to conform to.
This would allow for an easier migration/upgrade path when backward-incompatible changes need to be made to the spec. If a bower.json lacks a bower.json-spec-version-number, it should default to version "0" of the spec, for backward compatibility with old packages. Version 0 should be tagged retroactively as some commit circa the current version of the spec as of when this issue was filed. A bower.json using an outdated major version of the spec should at least emit a warning, and at most fail with an error if it's so old that supporting it is too burdensome for Bower or is bad public policy for Bower.

[sheerun]

I think instead of that we could introduce engines field, just like in npm.

"engines" : { "bower" : "~1.4.0" }

[cvrebert]

To clarify, are you suggesting using the Bower CLI tool's version number in engines or a spec-specific version number?

The problem with the former is there's (vexingly) no good correspondence between the Bower CLI tool and the spec. Also, e.g. if the Bower CLI tool added a bunch of wizards for doing things, that would necessitate a minor version bump, but bumping the engines version would be unnecessary busy work.

[sheerun]

I mean version of bower used (not the spec). As you said, there's not enough correspondence between bower and spec, so it's safer to require given bower version than the version of spec. Spec could define what bower version implements what (if any version implements it at all).

I don't think we need wizards for that.

[cvrebert]

"bower" would be the only valid key in engines, correct?

[sheerun]

I'm working on custom resolvers feature, so I guess we could include them as well..