Open ericclemmons opened 7 years ago
@daveashworth I assume you get notifications for issues here now ;)
@ericclemmons Man, the command you used should be fine for a pristine repo. I'd like to see if the same problem happens when you try it again after we merge in #11.
@ericclemmons 6.0.0 is published on npm.
Would you mind upgrading and trying again to see what happens?
Also either leave off the --dry-run
on the command (will write a CHANGELOG.md and set the version in package.json
but won't commit either). You can revert both these if needed.
or leave --dry-run
but append DEBUG=github-semantic-version:*
to the command to see all the debug output including the CHANGELOG.md that would be written.
Alright, so on my https://github.com/ericclemmons/tech-2016-lightning-talks repo, I ran:
> $(npm bin)/gsv --init
✔ Calculating the repo's current version
✔ Generating the changelog contents
WARNING!
The current version listed in package.json (1.0.0) is > the calculated version (0.0.7).
To ensure a consistent changelog, either make use of startVersion in your package.json, or label existing PRs as you would expect them to affect the repo version.
Even adding startVersion
resulted in the exact same output:
{
"name": "lightning",
"startVersion": "1.0.0",
"version": "1.0.0",
What's the best course of action here? Should I npm version 1.0.0
to start it off and then start using it?
@ericclemmons did you add a startVersion
to the gsv
section of your package.json
? Everything needs to be encapsulated there.
The wording on that error output may be confusing. It's updated in one of the pull requests to specify a gsv
section of package.json
.
Whoops.
One other thing that came up:
master
(no PRs).gsv
and the first tag would be v0.0.7
.Shouldn't the first release be v1.0.0
, no matter what the history was? In other words, all calculations are done from the first tag. Otherwise, it's v1.0.0
?
Should the first release always be v1.0.0
? I hesitate to make it that unless the user has either:
1) Tagged a PR with major
, or
2) Set the startVersion
In other words, I think we want to err on the side of being explicit/deterministic here vs assuming the user wanting the first release to be v1.0.0
.
This would be worth documenting how to adopt it in a new vs. existing repo.
I'm working on a new project (Only
initial commit
onmaster
and no merged PRs yet) & rangsv --init
: