Allow passing additional arguments to git-semver-tags

[Arcticon]

Preamble

The current implementation of git-semver-tags uses git log to retrieve information about git tags. This works fine for any workflow where one tags the default branch. Other workflows such as version branches, where additional tags are created, are not supported.

Problem

My usecase, version branches, is not fully supported, because tags on commits only live on their corresponding version branch:

tags 1.4.0, 1.4.1, ... live on branch 1.4
tags 1.5.0, 1.5.1, ... live on branch 1.5

The commits never reach the default branch and are therefore missing from the result of git-semver-tags.

Possible Solution

I have tried to use git tag instead of git log here. But to no avail.
There however is a possible solution that involves passing --all to git-semver-tags. This solves the issue where git-semver-tags only finds tags on the current branch.

There should be an option (always optional) for passing additional arguments to git-semver-tags:

commit-and-tag-version/lib/latest-semver-tag.js

Line 6 in fabd8cd

gitSemverTags({ tagPrefix }, function (err, tags) {

---

Should i propose a solution?

[Arcticon]

Would be good if #98 can be merged prior to any of this.

[TimothyJones]

I'm not sure I follow your use case - can you not just tag the commit when you cut the branch?

Are you making new commits on the version branches? That sounds like it could very quickly become non-trivial to reason about.

I'm not sure that passing --all would help - it would detect all the tags, sure, but it might lead to surprising or incorrect results.

[TimothyJones]

However, I do think that exposing the options for git-semver-tags is in-keeping with the existing patterns of passing options through to the underlying conventional-changelog packages, so that seems reasonable to me.

[Arcticon]

Are you making new commits on the version branches? That sounds like it could very quickly become non-trivial to reason about.

Yes, there could be. There might be a constellation where the default branch is way ahead of a version branch (lets say a feature was refactored and a bug ruled out), but there still is a bug on a version branch that needs fixing. Cherry picking is not a solution here, because there might be unwanted changes coming with it.
For us the default branch is always labeled as unstable.

Passing --all would help us in this case, because we only support 1 "legacy" version. There will never be 1/multiple higher version(s) when creating a changelog for an older version.

It might be that we do something weird and unusual. Would you recommend any change? :)

[Arcticon]

@TimothyJones do you have any updates?

[TimothyJones]

Apologies, I haven’t had a chance to look at a fix for this yet. I can get to it in a couple of weeks, or alternatively I’d be happy to review a PR if you’re able to raise one

[Arcticon]

Yeah, i can give it a go :)

[TimothyJones]

Would you recommend any change? :)

My experience is that it's better to roll forward if possible - where you try to keep all deployments / installations on the latest version with a linear history. This means you don't have to reason about whether changes in one version affect another, and you know that 2.3.x has all fixes that were in 2.2.x, etc.

This assumption is baked in to the way that commit-and-tag-version reasons about version bumps, so I think if you did pull all tags you might end up in a situation where you have surprising or conflicting results.

[TimothyJones]

Even ignoring which tool you use to track versions, I'm not sure how you'd communicate the implication of version changes to users - I don't think what you're doing is strictly against the letter of semver, but it might be against the spirit:

Semantic Versioning is all about conveying meaning by how the version number changes.

[Arcticon]

One improvement i immediately see is that prior to creating a version branch we can just tag the version on the default branch.
This will resolve any major or minor version bumps.

---

This means you don't have to reason about whether changes in one version affect another, and you know that 2.3.x has all fixes that were in 2.2.x, etc.

Once we bump/tag a major/minor version the default branch has technically the same code as the version branch. Only once changes, that should not make it into the current release, have been pushed to the default branch they differ.