Support for versions below the latest version in master about bitbucket-semver HOT 2 OPEN

@Rescla Thanks for the detailed report.

I'm thinking how and if we can get this working as you'd want. We'd need to look at the latest commit from a branch and try and find the most recent tag based on this. I may have a quick look at this over the weekend but no promises.

You'd need to be aware of tag collisions here though, e.g. 1.0.1 may already exist from main line, perhaps introduce a metadata tag e.g 1.0.1+hotfix.1

from bitbucket-semver.

@mikestead Thanks for the quick reply :)

My current workaround is this: https://gist.github.com/Rescla/1728ff5924bbc8aff1508d07e5a72052 and provide the latest version manually using --current. I resolve the current version using git describe release/1.0 --tags --abbrev=0, which will give me the most recent (unannotated) tag in the commit chain, which is 1.0.0 in this case.

This is a naive implementation though, since as you mentioned this might result in conflicting tags. However, if the caller is responsible for providing the base tag I think it is acceptable to also make them responsible for tag conflicts. That would work for me since we won't have patch pull requests in master, only in release branches. We treat non zero patch versions as hotfix versions always.

I'm thinking it should throw an error though, or return a status like 'unchanged' whenever you have two conflicting version chains.

Adding metadata feels a bit iffy to me since without knowing the branch structure I would think that they are two builds with the same functional scope, which is not the case. Returning 1.0.2 would not be acceptable I think, I would personally expect 1.0.2 to contain 1.0.1.

from bitbucket-semver.