Open slindberg opened 8 years ago
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.
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.
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...
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 is2.3.1
. What ends up happening is that the next tag is calculated off of2.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 before1.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.