Feature request

[fredrikatmainspringenergy]

Add a "sort" command, sorting version numbers read from STDIN.

[ranger6]

Thanks for your suggestion! Interest--and especially feedback on usage--is appreciated.

While I understand the request, it is a little terse. Do you have specific use cases in mind?

I have a few reservations about adding this new functionality:

1. semver-tool "is a little tool to manipulate version bumping in a project". It does go a bit beyond that, but not much. I look at it as a small helper for CI pipelines. Back to the use case: How would sorting be used in this context?
2. It is very convenient (except on Windows!) to have small tools written in bash: you get the source, nothing to compile or link, etc. However, bash is far from the best choice for data set handling (e.g. sorting files of structures). If you look around the web for tools to sort semantic versions, you find a couple bash scripts. But they are mostly wrappers to invoke other programs (e.g. GNU sort): what bash scripts are designed for. semver-tool has probably already pushed bash too far.
3. If sorting semantic version numbers is needed, I'd check out the various solutions available. One example might be Masterminds/semver. There is a command line wrapper: Masterminds/vert.

[fredrikatmainspringenergy]

Use case: auto-increment patch version on merge to master or release/ branches

# get current branch
BRANCH=$(git rev-parse --abbrev-ref HEAD)

# get all tags visible from current branch, sort them and pick the last (highest)
LATEST_TAG=$(git tags --merged ${BRANCH} | semver sort | tail -1)

# bump the highest visible version
NEW_TAG=$(semver bump patch ${LATEST_TAG})

# add tag
git tag -a "${NEW_TAG}" -m "<meaningful comment>"

# push tag
git push --tags origin

Here the sort option could also be a highest option, used to find the version to bump

[ranger6]

Thanks for the use case. I agree that this is a typical situation in a CI pipeline. And you have run into the problem that "bumping" a given version is easier than determining the given version. (see, for example, storing the semver value)

You note--and I tend to agree--that "highest" is really what you want. This code "almost" does it:

function newest {
    if [ $(semver compare "$1" "$2") -lt 0 ]
    then echo "$2"
    else echo "$1"
    fi
}

max="0.0.0"

for i in "$@"
do
    max=$(newest "$max" "$i")
done

echo "$max"

It seems to me that semver has the needed functionality (via compare) that one needs to write wrappers/code to get the job done. So, one question is whether or not it makes sense to incorporate some sort of "highest" function, adding to the API?

Currently, no commands read from stdin. So, returning the "highest" from stdin would be a funny direction to take. The above code returns the highest from the given arguments.

I mentioned that the code "almost" works. It fails when a tag like "0.0.0-rc1" exists. It fails when other tags (not semantic versions) exist. Your example code fails when there are no tags. I think the underlying problem is basing the "find-current-version-scheme" on git tags (and git itself).

This is not really a semver-tool issue. However, adding features to semver-tool to support a git scheme (or, in general, use of a list of versions to determine the current version) is less than convincing. And since a few lines of code to make the scheme work and enable this particular use case is quite reasonable, it seems best to keep semver-tool simple.

On the other hand, maybe "compare" is broken? Do people really use the returned value (-1,0,1) for logic other than selecting the newer value? It would be unfortunate if everyone was writing bash if-then-else's just to get the newest version when a function like semver newest <version> <other-version> would do the job. And, of course, "newest" could be generalised to zero or more arguments. Any ideas out there?

[fsaintjacques]

git-tag supports sorting by version with the git tag --sort=v:refname invocation. That won't work for all of semver specifications, but will likely work for the standard major.minor.patch pattern.

[ranger6]

I'm not seeing a lot of feedback on this issue. I'll mark it "won't fix" and see if this sparks something. Otherwise, after a while, it needs to go to the graveyard ...

[elopsod]

hi
we to need this functionality
add it please

[ranger6]

hi we to need this functionality add it please

It would be helpful if you could explain your specific use-case (see, for example, the use-case described above and the subsequent conversation). Also, the above discussion mentions issues with tag sorting and @fsaintjacques offered the git gist for the common case of semantic version string sorting. Do these tag sorting schemes not work for you? It would be interesting to know exactly why not if the feature is to be pursued.