search

absolute-version / commit-and-tag-version

Fork of the excellent standard-version. Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org :trophy:
ISC License
360 stars 33 forks source link

Allow passing additional arguments to git-semver-tags #152

Open Arcticon opened 1 month ago

Arcticon commented 1 month ago

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: https://github.com/absolute-version/commit-and-tag-version/blob/fabd8cd0525db0fc2f4c7d6aea1d39a764f3dfcc/lib/latest-semver-tag.js#L6

Should i propose a solution?

Arcticon commented 1 month ago

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

TimothyJones commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@TimothyJones do you have any updates?

TimothyJones commented 1 month ago

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 commented 1 month ago

Yeah, i can give it a go :)

TimothyJones commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.