changelog icon indicating copy to clipboard operation
changelog copied to clipboard

git: annotated tags and custom tag name

Open akoenig opened this issue 11 years ago • 6 comments

@defunctzombie Awesome tool! Thanks for building and publishing it!

Are you planning support for annotated git tags and custom tag names?

Would be really cool if one could change the tag name from

git tag v<new version>

to an annotated version

git tag -a "<new version>" -m "<custom><new version>"

I prefer to omit the "v" prefix in front of my tags for example, like:

git tag -a "1.0.0" -m "Release 1.0.0"

Let me know what you think about that and if a PR is appreciated :)

akoenig avatar May 23 '14 07:05 akoenig

i think this would be more of a .changelogrc thing vs. an actual options. i've already thought of a lot of these possible options whose implementation would be much more complex than the rest of this module

jonathanong avatar May 23 '14 07:05 jonathanong

Agree. Can you give examples of these options? I also think that a .changelogrc would be great for this use case, but if I read your response correct it is not on the roadmap, right?

.changelogrc:

{
    "tags": {
        "annotated": true,
        "format": "{{version}}"
    }
}

akoenig avatar May 23 '14 08:05 akoenig

+1 for this idea. I've always been opposed to adding 'v' in tag names as it's redundant and meaningless.

akiva avatar May 30 '14 16:05 akiva

I personally like the v tho I think a $HOME/.changelogrc or .changelogrc in the project could be a nice way to allow configuring this. I think an RC file is good since others can use the same settings when releasing a project.

Overall tho I think this is a silly thing to configure. Just accept that a v will be there and move on with life :)

defunctzombie avatar May 30 '14 16:05 defunctzombie

@defunctzombie My intention is to realize a possibility to switch to annotated tags. If configuring the format of the tag message makes sense ... – definitely debatable. :)

Anyways, I created a solution for that in my fork (https://github.com/akoenig/changelog/commit/8c9029ca055e625e9d41bcdce4b3c772a24a263d). Maybe you have the time to look if this is a proper solution for a PR :)

akoenig avatar May 30 '14 16:05 akoenig

I would vote for adhering to XDG base directory specification ($XDG_CONFIG_HOME) for the location of the configuration file.

akiva avatar May 31 '14 02:05 akiva