Pristine Repo Usage?

[ericclemmons]

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 on master and no merged PRs yet) & ran gsv --init:

> jest-storybook@1.0.0 release /Users/Eric/Projects/ericclemmons/jest-storybook
> github-semantic-version "--init" "--dry-run"

  github-semantic-version:info Current branch: 1-initial-release +0ms
  github-semantic-version:info Release branch: master +2ms
  github-semantic-version:info Dry-run enabled +1ms
  github-semantic-version:info Executing: git config --get remote.origin.url +1ms
  github-semantic-version:info User: ericclemmons +11ms
  github-semantic-version:info Repo: jest-storybook +0ms
  github-semantic-version:info Fetching all merged pull requests for the repo... +20ms
undefined

[ericclemmons]

@daveashworth I assume you get notifications for issues here now ;)

[daveashworth]

@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.

[daveashworth]

@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.

[ericclemmons]

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?

[daveashworth]

@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.

[ericclemmons]

Whoops.

[ericclemmons]

One other thing that came up:

1. Pristine repo, has a couple commits on master (no PRs).
2. I run 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?

[daveashworth]

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.