Base next semver tag off of version in package.json instead of latest

[slindberg]

Most of the time, the version that is in package.json reflects the latest tag. However this is not the case when creating releases off of stable branches, e.g. the package version is 1.13.4 when the latest version is 2.3.1. What ends up happening is that the next tag is calculated off of 2.3.1, forcing the user to specify the tag manually with the --tag option.

I can't think of an use case for not wanting to base the next version off of what is currently in package.json. This would be a breaking change so would have to happen before 1.0.0, although would likely not require action on the user's part.

A third current key could be added to the hash passed to hooks, to give access to this version without breaking backwards compatibility.

[slindberg]

One possible issue is the case where the calculated version already exists as a tag, e.g. if the user specifies --major in the example given above.

[slindberg]

This also will mean having to change the getNextTag strategy method to take the current version. Passing an array of tags (with v prefix) and a raw version (no v) is crappy. Perhaps it makes more sense for all prefix handling to be done outside of the strategy methods, so that they deal only with actual versions.

[rwjblue]

I can't think of an use case for not wanting to base the next version off of what is currently in package.json.

Because you made a mistake and are on the wrong branch :stuck_out_tongue_winking_eye:

---

Maybe we shouldn't try to handle this perfectly all the time, but rather detect that the package.json doesn't agree with our current key and either exit stating that --tag would be needed or prompt for what they want done...