ericclemmons/github-semantic-version

Pristine Repo Usage?

ericclemmons opened this issue · 8 comments

ericclemmons commented

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 commented

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

  • 👍1
daveashworth commented

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

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

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 commented

@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 commented
ericclemmons commented

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 commented

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.