Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tagging npm versions as git releases #7

Open
RichardLitt opened this issue Jul 27, 2017 · 5 comments
Open

Tagging npm versions as git releases #7

RichardLitt opened this issue Jul 27, 2017 · 5 comments
Labels

Comments

@RichardLitt
Copy link
Owner

I never release my npm modules or GitHub code as releases, and I've no real idea why I should. According to Yoshua, this would help me in a few ways: "Ideally you'd also keep a changelog, list of commits and contributors. Also npm creates git tags which GitHub reads as releases." But I'm not really sure what this means.

Unanswered questions

  • How is a codebase improved by having a changelog and/or list of contributors in a release?
  • What is the benefit of a git tag from npm?
  • What are the benefits of releases, in general?
  • Should I changelog everything?
  • Should I be adding contributor lists to everything?
@hackergrrl
Copy link

How are pushing new versions now? Are you manually editing package.json or using the npm version command?

How is a codebase improved by having a changelog and/or list of contributors in a release?

Good reading: http://keepachangelog.com/en/1.0.0/

What is the benefit of a git tag from npm?

Sometimes it's useful to be able to type git checkout v2.3.0 and work with the code at that version.

What are the benefits of releases, in general?

I think they're useful for applications, but less so for modules or npm install --global programs.

@RichardLitt
Copy link
Owner Author

RichardLitt commented Jul 31, 2017

I use geopkg:

## For using normal npm
function npmv () {
  geopkg version "$1"
}

Sometimes it's useful to be able to type git checkout v2.3.0 and work with the code at that version.

This makes sense!

I think they're useful for applications, but less so for modules or npm install --global programs.

Agreed. Ok. I am going to not worry about them for my own modules, then. This was my primary thinking.

@hackergrrl
Copy link

Weird: when I look at https://github.com/RichardLitt/generator-standard-readme I don't see any tags for it. What happens when you run git push --tags?

@RichardLitt
Copy link
Owner Author

🐕  git push --tags
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:RichardLitt/generator-standard-readme.git
 * [new tag]         v0.0.1 -> v0.0.1
 * [new tag]         v0.0.2 -> v0.0.2
 * [new tag]         v0.0.4 -> v0.0.4
 * [new tag]         v0.0.5 -> v0.0.5
 * [new tag]         v0.0.6 -> v0.0.6
 * [new tag]         v0.0.9 -> v0.0.9
 * [new tag]         v0.1.0 -> v0.1.0
 * [new tag]         v0.1.2 -> v0.1.2
 * [new tag]         v0.1.3 -> v0.1.3
 * [new tag]         v0.1.4 -> v0.1.4
 * [new tag]         v0.2.0 -> v0.2.0
 * [new tag]         v1.0.1 -> v1.0.1
 * [new tag]         v1.0.2 -> v1.0.2
 * [new tag]         v1.0.3 -> v1.0.3

... Why weren't these pushed before? Do you need to explicitly push them?

@hackergrrl
Copy link

hackergrrl commented Aug 1, 2017

Yes, the default is to explicitly push them.

I use this handy little shell alias for pushing, so I don't forget about tags:

alias npp='npm test && git p && git p --tags && npm publish'

@RichardLitt RichardLitt added the js label Aug 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants