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

Adding tag with semantic version release format #20

Open
sanrut01 opened this issue Nov 23, 2021 · 10 comments
Open

Adding tag with semantic version release format #20

sanrut01 opened this issue Nov 23, 2021 · 10 comments

Comments

@sanrut01
Copy link
Contributor

The pre-commit usage currently the best practice is using tags as revision rather than branches.
This helps us to use the previous version of the code base as well.

Can this project be tagged with the current code base by using semantic version format and can be taken further whenever a change is merged to master and have to be released

@jlebar
Copy link
Owner

jlebar commented Nov 23, 2021

Sounds reasonable to me. Patches welcome.

Would you also be willing to link to the documentation that explains the current best practice?

@sanrut01
Copy link
Contributor Author

You can look for https://semver.org/
and there is some node package to use semantic release to manage but i also need to have look into it
https://github.com/semantic-release/semantic-release/tree/master/docs/usage
But as of now if we can tag with current branch then we can look into this as improvement to automate semantic release for our repo

@jlebar
Copy link
Owner

jlebar commented Nov 24, 2021

Is there documentation saying that in pre-commit specifically, the best practice is to use semver?

@sanrut01
Copy link
Contributor Author

sanrut01 commented Nov 24, 2021

I haven't found any specific to pre-commit , when we use branch name for rev we get the warning below:
[WARNING] The 'rev' field of repo 'https://github.com/Lucas-C/pre-commit-hooks-nodejs' appears to be a mutable reference (moving tag / branch). Mutable references are never updated after the first install and are not supported. See https://pre-commit.com/#using-the-latest-version-for-a-repository for more details.

Ideally, when we use to tag the semantic version is the one that is used and suggested as best practice.

@jlebar
Copy link
Owner

jlebar commented Nov 24, 2021

OK, that warning makes sense.

Why not just type in a sha, though?

@sanrut01
Copy link
Contributor Author

sanrut01 commented Nov 24, 2021

We can but whatever examples are other pre-commits i see they have used the tag everywhere rather than the hash.
Another scenario would what would be a case of rebasing if we use commit sha as the commit shas can change after rebase and tag may not be the same as of sha.

I am open to commit sha or semver somehow feel semver would be good

@jlebar
Copy link
Owner

jlebar commented Nov 24, 2021

Another scenario would what would be a case of rebasing if we use commit sha as the commit shas can change after rebase and tag may not be the same as of sha.

By design, git tags can't change. If you want a "tag-like thing" that can change, you want a branch. But then the thing that they're warning you about in the error you copied applies.

It seems like the Simplest Thing That Could Possibly Work would be to use sha's. Does that sound OK to you for now?

@sanrut01
Copy link
Contributor Author

Sounds good. Please go ahead with creating the tag

@jlebar
Copy link
Owner

jlebar commented Nov 25, 2021 via email

@santhu3064
Copy link

Sorry i misread your precious message.
Sounds sensible will use the commit sha

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

3 participants