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

[RRFC] Set version. Don't tag per default. #659

Open
infacto opened this issue Dec 8, 2022 · 3 comments
Open

[RRFC] Set version. Don't tag per default. #659

infacto opened this issue Dec 8, 2022 · 3 comments

Comments

@infacto
Copy link

infacto commented Dec 8, 2022

Suggestion: Don't create Git tags by default. Invert the logic of --no-git-tag-version. The dev should add option like --git-tag or just --tag to automatically create a tag. In my opinion we (e.g. CI) should have full control when and how to commit and tag. It's more error-prone to tag by default.

https://docs.npmjs.com/cli/commands/npm-version

@ljharb
Copy link
Contributor

ljharb commented Dec 8, 2022

How is it more error prone? An undesired tag can simply be deleted, but a missing tag might be harder to reconstruct later.

@infacto
Copy link
Author

infacto commented Dec 9, 2022

Well, there are several reasons or cases. At first we have to say that this method creates a commit and tag. And in my case I accidentally created this tags and commits. I didn't know that. I wrote and tested a CI script which executed npm version with garbage versions to test with a script that requires the version in the package.json for further changes on the repo before commit and tag. So I wanted to increase the version and further stuff before tagging. I didn't realiszed that this method created unwanted commits and tags. In my opinion this function should be explicitly enabled by the dev using the argument. In this case, there can never be cases like mine. No unintentional changes in Git before I decide to do it. ... I know this would be a breaking change for the devs who already uses it in believing to affect git. But not really critical in my opinion.

@ljharb
Copy link
Contributor

ljharb commented Dec 9, 2022

Right - so in your case, the worst damage was some extra commits and tags, in a version control system that lets you get rid of them without a trace.

If the change you're requesting happens, the worst damage is that information is irretrievably lost forever.

It seems clear to me which default is safest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants