Pristine Repo Usage? #17

Activity

1. ericclemmons

   added

   question

   on Dec 4, 2016
2. ericclemmons commented on Dec 4, 2016

   

   ericclemmons

   on Dec 4, 2016

   OwnerAuthor

   More actions

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

   👍React with 👍1Reacted by Dave Ashworth
3. daveashworth commented on Dec 5, 2016

   

   daveashworth

   on Dec 5, 2016

   Last edited by daveashworth

   Collaborator

   More actions

   @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.
4. daveashworth commented on Dec 5, 2016

   

   daveashworth

   on Dec 5, 2016

   Last edited by daveashworth

   Collaborator

   More actions

   @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.
5. ericclemmons commented on Dec 12, 2016

   

   ericclemmons

   on Dec 12, 2016

   OwnerAuthor

   More actions

   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?
6. daveashworth commented on Dec 12, 2016

   

   daveashworth

   on Dec 12, 2016

   Last edited by daveashworth

   Collaborator

   More actions

   @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.
7. ericclemmons commented on Dec 12, 2016

   

   ericclemmons

   on Dec 12, 2016 via email

   Last edited by ericclemmons

   OwnerAuthor

   More actions

   Whoops.
8. ericclemmons commented on Dec 28, 2016

   

   ericclemmons

   on Dec 28, 2016

   OwnerAuthor

   More actions

   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?
9. daveashworth commented on Jan 3, 2017

   

   daveashworth

   on Jan 3, 2017

   Collaborator

   More actions

   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.