Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Calculate Next Suitable Version Tag for Your Git based project
#!/usr/bin/env bash
## Copyright (C) 2017, Oleksandr Kucherenko
## Last revisit: 2017-09-29
## Bug fixes: 2021-06-09, @slmingol changes applied
# For help:
# ./versionip.sh --help
# For developer / references:
# https://ryanstutorials.net/bash-scripting-tutorial/bash-functions.php
# http://tldp.org/LDP/abs/html/comparison-ops.html
# https://misc.flogisoft.com/bash/tip_colors_and_formatting
## display help
function help(){
echo 'usage: ./version-up.sh [-r|--release] [-a|--alpha] [-b|--beta] [-c|--release-candidate]'
echo ' [-m|--major] [-i|--minor] [-p|--patch] [-e|--revision] [-g|--git-revision]'
echo ' [--stay] [--default] [--help]'
echo ''
echo 'Switches:'
echo ' --release switch stage to release, no suffix, -r'
echo ' --alpha switch stage to alpha, -a'
echo ' --beta switch stage to beta, -b'
echo ' --release-candidate switch stage to rc, -c'
echo ' --major increment MAJOR version part, -m'
echo ' --minor increment MINOR version part, -i'
echo ' --patch increment PATCH version part, -p'
echo ' --revision increment REVISION version part, -e'
echo ' --git-revision use git revision number as a revision part, -g'
echo ' --stay compose version.properties but do not do any increments, -s'
echo ' --default increment last found part of version, keeping the stage. Increment applied up to MINOR part.'
echo ' --apply run GIT command to apply version upgrade'
echo ''
echo 'Version: MAJOR.MINOR[.PATCH[.REVISION]][-STAGE]'
echo ''
echo 'Reference:'
echo ' http://semver.org/'
echo ''
echo 'Versions priority:'
echo ' 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc < 1.0.0'
exit 0
}
## get highest version tag for all branches
function highest_tag(){
local TAG=$(git tag --list 2>/dev/null | sort -V | tail -n1 2>/dev/null)
echo "$TAG"
}
## extract current branch name
function current_branch(){
## expected: heads/{branch_name}
## expected: {branch_name}
local BRANCH=$(git rev-parse --abbrev-ref HEAD | cut -d"/" -f2)
echo "$BRANCH"
}
## get latest/head commit hash number
function head_hash(){
local COMMIT_HASH=$(git rev-parse --verify HEAD)
echo "$COMMIT_HASH"
}
## extract tag commit hash code, tag name provided by argument
function tag_hash(){
local TAG_HASH=$(git log -1 --format=format:"%H" $1 2>/dev/null | tail -n1)
echo "$TAG_HASH"
}
## get latest tag in specified branch
function latest_tag(){
#local TAG=$(git describe --tags $(git rev-list --tags --max-count=1 2>/dev/null) 2>/dev/null)
local TAG=$(git describe --tags --abbrev=0 2>/dev/null)
echo "$TAG"
}
## get latest revision number
function latest_revision(){
local REV=$(git rev-list --count HEAD 2>/dev/null)
echo "$REV"
}
## parse last found tag, extract it PARTS
function parse_last(){
local position=$(($1-1))
# two parts found only
local SUBS=( ${PARTS[$position]//-/ } )
#echo ${SUBS[@]}, size: ${#SUBS}
# found NUMBER
PARTS[$position]=${SUBS[0]}
#echo ${PARTS[@]}
# found SUFFIX
if [[ ${#SUBS} -ge 1 ]]; then
PARTS[4]=${SUBS[1],,} #lowercase
#echo ${PARTS[@]}, ${SUBS[@]}
fi
}
## increment REVISION part, don't touch STAGE
function increment_revision(){
PARTS[3]=$(( PARTS[3] + 1 ))
IS_DIRTY=1
}
## increment PATCH part, reset all other lower PARTS, don't touch STAGE
function increment_patch(){
PARTS[2]=$(( PARTS[2] + 1 ))
PARTS[3]=0
IS_DIRTY=1
}
## increment MINOR part, reset all other lower PARTS, don't touch STAGE
function increment_minor(){
PARTS[1]=$(( PARTS[1] + 1 ))
PARTS[2]=0
PARTS[3]=0
IS_DIRTY=1
}
## increment MAJOR part, reset all other lower PARTS, don't touch STAGE
function incremet_major(){
PARTS[0]=$(( PARTS[0] + 1 ))
PARTS[1]=0
PARTS[2]=0
PARTS[3]=0
IS_DIRTY=1
}
## increment the number only of last found PART: REVISION --> PATCH --> MINOR. don't touch STAGE
function increment_last_found(){
if [[ "${#PARTS[3]}" == 0 || "${PARTS[3]}" == "0" ]]; then
if [[ "${#PARTS[2]}" == 0 || "${PARTS[2]}" == "0" ]]; then
increment_minor
else
increment_patch
fi
else
increment_revision
fi
# stage part is not EMPTY
if [[ "${#PARTS[4]}" != 0 ]]; then
IS_SHIFT=1
fi
}
## compose version from PARTS
function compose(){
MAJOR="${PARTS[0]}"
MINOR=".${PARTS[1]}"
PATCH=".${PARTS[2]}"
REVISION=".${PARTS[3]}"
SUFFIX="-${PARTS[4]}"
if [[ "${#PATCH}" == 1 ]]; then # if empty {PATCH}
PATCH=""
fi
if [[ "${#REVISION}" == 1 ]]; then # if empty {REVISION}
REVISION=""
fi
if [[ "${PARTS[3]}" == "0" ]]; then # if revision is ZERO
REVISION=""
fi
# shrink patch and revision
if [[ -z "${REVISION// }" ]]; then
if [[ "${PARTS[2]}" == "0" ]]; then
PATCH=""
fi
else # revision is not EMPTY
if [[ "${#PATCH}" == 0 ]]; then
PATCH=".0"
fi
fi
# remove suffix if we don't have a alpha/beta/rc
if [[ "${#SUFFIX}" == 1 ]]; then
SUFFIX=""
fi
echo "${MAJOR}${MINOR}${PATCH}${REVISION}${SUFFIX}" #full format
}
# initial version used for repository without tags
INIT_VERSION=0.0.0.0-alpha
# do GIT data extracting
TAG=$(latest_tag)
REVISION=$(latest_revision)
BRANCH=$(current_branch)
TOP_TAG=$(highest_tag)
TAG_HASH=$(tag_hash $TAG)
HEAD_HASH=$(head_hash)
# do we have any GIT tag for parsing?!
echo ""
if [[ -z "${TAG// }" ]]; then
TAG=$INIT_VERSION
echo No tags found.
else
echo Found tag: $TAG in branch \'$BRANCH\'
fi
# print current revision number based on number of commits
echo Current Revision: $REVISION
echo Current Branch: $BRANCH
echo ""
# if tag and branch commit hashes are different, than print info about that
#echo $HEAD_HASH vs $TAG_HASH
if [[ "$@" == "" ]]; then
if [[ "$TAG_HASH" == "$HEAD_HASH" ]]; then
echo "Tag $TAG and HEAD are aligned. We will stay on the TAG version."
echo ""
NO_ARGS_VALUE='--stay'
else
PATTERN="^[0-9]+.[0-9]+(.[0-9]+)*(-(alpha|beta|rc))*$"
if [[ "$BRANCH" =~ $PATTERN ]]; then
echo "Detected version branch '$BRANCH'. We will auto-increment the last version PART."
echo ""
NO_ARGS_VALUE='--default'
else
echo "Detected branch name '$BRANCH' than does not match version pattern. We will increase MINOR."
echo ""
NO_ARGS_VALUE='--minor'
fi
fi
fi
#
# {MAJOR}.{MINOR}[.{PATCH}[.{REVISION}][-(.*)]
#
# Suffix: alpha, beta, rc
# No Suffix --> {NEW_VERSION}-alpha
# alpha --> beta
# beta --> rc
# rc --> {VERSION}
#
PARTS=( ${TAG//./ } )
parse_last ${#PARTS[@]} # array size as argument
#echo ${PARTS[@]}
# if no parameters than emulate --default parameter
if [[ "$@" == "" ]]; then
set -- $NO_ARGS_VALUE
fi
# parse input parameters
for i in "$@"
do
key="$i"
case $key in
-a|--alpha) # switched to ALPHA
PARTS[4]="alpha"
IS_SHIFT=1
;;
-b|--beta) # switched to BETA
PARTS[4]="beta"
IS_SHIFT=1
;;
-c|--release-candidate) # switched to RC
PARTS[4]="rc"
IS_SHIFT=1
;;
-r|--release) # switched to RELEASE
PARTS[4]=""
IS_SHIFT=1
;;
-p|--patch) # increment of PATCH
increment_patch
;;
-e|--revision) # increment of REVISION
increment_revision
;;
-g|--git-revision) # use git revision number as a revision part§
PARTS[3]=$(( REVISION ))
IS_DIRTY=1
;;
-i|--minor) # increment of MINOR by default
increment_minor
;;
--default) # stay on the same stage, but increment only last found PART of version code
increment_last_found
;;
-m|--major) # increment of MAJOR
incremet_major
;;
-s|--stay) # extract version info
IS_DIRTY=1
NO_APPLY_MSG=1
;;
--apply)
DO_APPLY=1
;;
-h|--help)
help
;;
esac
shift
done
# detected shift, but no increment
if [[ "$IS_SHIFT" == "1" ]]; then
# temporary disable stage shift
stage=${PARTS[4]}
PARTS[4]=''
# detect first run on repository, INIT_VERSION was used
if [[ "$(compose)" == "0.0" ]]; then
increment_minor
fi
PARTS[4]=$stage
fi
# no increment applied yet and no shift of state, do minor increase
if [[ "$IS_DIRTY$IS_SHIFT" == "" ]]; then
increment_minor
fi
# instruct user how to apply new TAG
echo -e "Proposed TAG: \033[32m$(compose)\033[0m"
echo ''
# is proposed tag in conflict with any other TAG
PROPOSED_HASH=$(tag_hash $(compose))
if [[ "${#PROPOSED_HASH}" -gt 0 && "$NO_APPLY_MSG" == "" ]]; then
echo -e "\033[31mERROR:\033[0m "
echo -e "\033[31mERROR:\033[0m Found conflict with existing tag \033[32m$(compose)\033[0m / $PROPOSED_HASH"
echo -e "\033[31mERROR:\033[0m Only manual resolving is possible now."
echo -e "\033[31mERROR:\033[0m "
echo -e "\033[31mERROR:\033[0m To Resolve try to add --revision or --patch modifier."
echo -e "\033[31mERROR:\033[0m "
echo ""
fi
if [[ "$NO_APPLY_MSG" == "" ]]; then
echo 'To apply changes manually execute the command(s):'
echo -e "\033[90m"
echo " git tag $(compose)"
echo " git push origin $(compose)"
echo -e "\033[0m"
fi
# compose version override file
if [[ "$TAG" == "$INIT_VERSION" ]]; then
TAG='0.0'
fi
VERSION_FILE=version.properties
echo "# $(date)" >${VERSION_FILE}
echo snapshot.version=$(compose) >>${VERSION_FILE}
echo snapshot.lasttag=$TAG >>${VERSION_FILE}
echo snapshot.revision=$REVISION >>${VERSION_FILE}
echo snapshot.hightag=$TOP_TAG >>${VERSION_FILE}
echo snapshot.branch=$BRANCH >>${VERSION_FILE}
echo '# end of file' >>${VERSION_FILE}
# should we apply the changes
if [[ "$DO_APPLY" == "1" ]]; then
echo ''
echo "Applying git repository version up... no push, only local tag assignment!"
echo ''
git tag $(compose)
# confirm that tag applied
git --no-pager log --pretty=format:"%h%x09%Cblue%cr%Cgreen%x09%an%Creset%x09%s%Cred%d%Creset" -n 2 --date=short | nl -w2 -s" "
echo ''
echo ''
fi
#
# Major logic of the script - "on each run script propose future version of the product".
#
# - if no tags on project --> propose '0.1-alpha'
# - do multiple build iterations until you become satisfied with result
# - run 'version-up.sh --apply' to save result in GIT
#
@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Sep 6, 2016

Samples/Usage:
By default we increment MINOR segment, that correspond introducing of a new feature.

$ ./versionup.sh

Found tag: 5.7-RC
Current Revision: 19

Proposed TAG: 5.8-rc

To apply changes execute the command:

  git tag 5.8-rc
  git push origin 5.8-rc
@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Sep 6, 2016

Switch to RELEASE and increase the patch segment:

$ ./versionup.sh --patch --release

Found tag: 5.7-RC
Current Revision: 19

Proposed TAG: 5.7.1

To apply changes execute the command:

  git tag 5.7.1
  git push origin 5.7.1

Switch to RELEASE and Increment Revision:

$ ./versionup.sh --revision --release

Found tag: 5.7-RC
Current Revision: 19

Proposed TAG: 5.7.0.20

To apply changes execute the command:

  git tag 5.7.0.20
  git push origin 5.7.0.20

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Sep 6, 2016

#
# {MAJOR}.{MINOR}[.{PATCH}[.{REVISION}][-(.*)]
#
#  Suffix: alpha, beta, rc
#    No Suffix --> {NEW_VERSION}-alpha
#    alpha --> beta
#    beta --> rc
#    rc --> {VERSION}

Help:

$ ./versionup.sh --help

Found tag: 5.7-RC
Current Revision: 19

usage: ./versionup.sh [-r|--release] [-a|--alpha] [-b|--beta] [-c|--release-candidate]
                      [-p|--patch] [-e|--revision] [--default] [-m|--major]
                      [--help]

Switches:
  --release           switch stage to release, no suffix
  --alpha             switch stage to alpha
  --beta              switch stage to beta
  --release-candidate switch stage to rc
  --major             increment MAJOR version part
  --default           increment MINOR version part
  --patch             increment PATCH version part
  --revision          increment REVISION version part

Version: MAJOR.MINOR[.PATCH[.REVISION]][-STAGE]

Reference:
  http://semver.org/

Versions priority:
  1.0.0-alpha < 1.0.0-beta < 1.0.0-rc < 1.0.0

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Sep 29, 2017

Found tag: 10.0.1 in branch 'hotfixes-v10'
Current Revision: 2206
Current Branch: hotfixes-v10

Detected branch name 'hotfixes-v10' than does not match version pattern. We will increase MINOR.

usage: ./version-up.sh [-r|--release] [-a|--alpha] [-b|--beta] [-c|--release-candidate]
                      [-m|--major] [-i|--minor|--default] [-p|--patch] [-e|--revision]
                      [--help]

Switches:
  --release           switch stage to release, no suffix, -r
  --alpha             switch stage to alpha, -a
  --beta              switch stage to beta, -b
  --release-candidate switch stage to rc, -c
  --major             increment MAJOR version part, -m
  --minor             increment MINOR version part, -i
  --patch             increment PATCH version part, -p
  --revision          increment REVISION version part, -e
  --git-revision      use git revision number as a revision part, -g
  --stay              compose version.properties but do not do any increments, -s
  --default           increment last found part of version, keeping the stage. Increment applyied up to MINOR part.
  --apply             run GIT command to apply version upgrade

Version: MAJOR.MINOR[.PATCH[.REVISION]][-STAGE]

Reference:
  http://semver.org/

Versions priority:
  1.0.0-alpha < 1.0.0-beta < 1.0.0-rc < 1.0.0

Added more smart logic. If detected branch with the version TAG pattern, script will try to auto-increment the last part of version.

Added detection of existing tag. If proposed tag matches already existing tag, will be displayed error message:

screen shot 2017-09-29 at 11 53 09

@Br3nda

This comment has been minimized.

Copy link

@Br3nda Br3nda commented Jan 15, 2019

What license is this code under? Can i used it under an open source licence?

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Feb 12, 2019

@Br3nda yes its open source, you can use it if keep author name in script

@thuitaw

This comment has been minimized.

Copy link

@thuitaw thuitaw commented Apr 22, 2020

Thank you very much for this script!!

To get the proposed tag from the script I use
proposed_tag=`./version.sh --patch --release | grep "TAG" | awk '{split($0, a, ":"); print a[2]}' | gsed 's/\x1b\[[0-9;]*m//g' | sed -e 's/^[[:space:]]*//'` which works OK.

This is if you need to store the proposed tag (eg maybe in the env) and use it for something else (release notes, etc)
Do tell me if there's an easier way to do this.. i suspect there is.

Thanks again for this!!

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Apr 23, 2020

Do tell me if there's an easier way to do this.. i suspect there is.

Did you check the version.properties file?

https://gist.github.com/OleksandrKucherenko/9fb14f81a29b46886ccd63b774c5959f#file-version-up-sh-L358-L364

gradle/version-up.sh && cat version.properties

Found tag: 0.3.1 in branch 'master'
Current Revision: 70
Current Branch: master

Tag 0.3.1 and HEAD are aligned. We will stay on the TAG version.

Proposed TAG: 0.3.1

# Fri Apr 24 13:13:39 CEST 2020
snapshot.version=0.3.1
snapshot.lasttag=0.3.1
snapshot.revision=70
snapshot.hightag=0.3.1
snapshot.branch=master
# end of file
gradle/version-up.sh --major && cat version.properties

Found tag: 0.3.1 in branch 'master'
Current Revision: 70
Current Branch: master

Proposed TAG: 1.0

To apply changes manually execute the command(s):

  git tag 1.0
  git push origin 1.0

# Fri Apr 24 13:13:51 CEST 2020
snapshot.version=1.0
snapshot.lasttag=0.3.1
snapshot.revision=70
snapshot.hightag=0.3.1
snapshot.branch=master
# end of file

snapshot.version=1.0 contains needed to your version number.

cat version.properties | grep snapshot.version | awk -F '=' '{print $2}'

check this @thuitaw

@thuitaw

This comment has been minimized.

Copy link

@thuitaw thuitaw commented Apr 28, 2020

Hey @OleksandrKucherenko Thanks for pointing this out

@sadortun

This comment has been minimized.

Copy link

@sadortun sadortun commented Oct 23, 2020

Hey @OleksandrKucherenko, You really should make a repo with this :)

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Oct 28, 2020

@sadortun I still think its too small for a separated repo

@sadortun

This comment has been minimized.

Copy link

@sadortun sadortun commented Oct 28, 2020

@OleksandrKucherenko small, yes, but It would give people a chance to open issues and submit PRs. You did an amazing job, but there Is still a few more improvement to do :)

@nicknezis

This comment has been minimized.

Copy link

@nicknezis nicknezis commented Feb 18, 2021

@OleksandrKucherenko This is really great. Could you provide a brief description of the development and release workflow that this script best fits? I'm eager to integrate something like this into an automated CI system, but need to first understand how best to use it.

How would you recommend a developer use the script vs an automated CI system use the script?

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Feb 22, 2021

@OleksandrKucherenko This is really great. Could you provide a brief description of the development and release workflow that this script best fits? I'm eager to integrate something like this into an automated CI system, but need to first understand how best to use it.

How would you recommend a developer use the script vs an automated CI system use the script?

Is script documentation not enough?! OK... @nicknezis

  • GIT repository enabled project required.
  • Developer execute version-up.sh script for composing version.properties file.
  • Script is smart and depends on state of the git applies different version increment strategies on run.
  • Developer also may customize script behavior by flags and force different version increments.
  • Major scenario: developer may switch state of the project to alpha, beta, release candidate or release state. (also known as stage)
  • Depends on type of modification developer may force "patch" part of the version modification, instead of default "feature" part. script is smart and depends on incremented part improves version number.
  • when developer satisfied with state of the project, can be set a version git tag.
  • when developer works in branch that has a version tag - script detects it and propose next version number based on that info.
@nicknezis

This comment has been minimized.

Copy link

@nicknezis nicknezis commented Feb 22, 2021

Thank you. This is helpful. I'm sorry if my questions were a little bit nebulous.

Your description is very helpful. Some remaining questions for clarity.

  1. Does a developer run the script manually and generate the version.properties file with that file being checked into Git? Or does the script get called by the build tool/CI to dynamically generate the current version? (This is something I've seen in the Gradle Nebula Release plugin)
  2. Does it work when releasing from branch as opposed to release from trunk?
  3. If a team of engineers are working on a repo, could they bump the version in their feature branches? Or would it have to be bumped after merging back into master? Based on some of the bullet points you mentioned, this seems like it might be covered which would be really cool.

Thanks again for the script and the answers. I really appreciate it. It's helpful in understanding before I recommend to a larger team for use.

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Feb 23, 2021

  1. Does a developer run the script manually and generate the version.properties file with that file being checked into Git? Or does the script get called by the build tool/CI to dynamically generate the current version? (This is something I've seen in the Gradle Nebula Release plugin)

No, script is not a part of anything else. It's designed for manual and CI/CD execution. The dev should identify the best way to call it.

I usually do script execution as a first build step for CI/CD or local builds.

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Feb 23, 2021

2. Does it work when releasing from branch as opposed to release from trunk?

  • if you in master branch - script verify do we have any commits from last version tag or not, and based on this information decide which version to propose. (btw for new repositories we can have main instead of master!)
  • we on master, new commit added after last version tag -> increase minor/feature segment of the version
  • we on master, no new commits after last version tag -> "we are building specific version", script extract version from version tag

script work for trunk and for other branches.

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Feb 23, 2021

3. If a team of engineers are working on a repo, could they bump the version in their feature branches? Or would it have to be bumped after merging back into master? Based on some of the bullet points you mentioned, this seems like it might be covered which would be really cool.

if you doing modification in branch - that treated as a "hot fix" for a specific version. Than developer should run script and make a decision which segment of the version should be modified...

master -- tag:1.0.0.0 --> commits --> HEAD
              \----- branch --- version. 1.0.1.0 (developer decide to increase a patch segment)

I highly recommend to cherry-pick changes from release branches into main/master... that will keep master in good state

@vlauciani

This comment has been minimized.

Copy link

@vlauciani vlauciani commented Mar 1, 2021

Hi

Thank you very much for this script, I think you should make a dedicated repo...

I've a question: does it work with prefix on TAG? I noticed that the MAGIOR doesn't increase If it has a prefix. For example:

./version-up.sh -m

Found tag: v2.14.1 in branch 'master'
Current Revision: 192
Current Branch: master

Proposed TAG: 1.0

To apply changes manually execute the command(s):

  git tag 1.0
  git push origin 1.0

If I understand correctly, expected output should be: Proposed TAG: v3.0

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Mar 2, 2021

Hi

Thank you very much for this script, I think you should make a dedicated repo...

I've a question: does it work with prefix on TAG? I noticed that the MAGIOR doesn't increase If it has a prefix. For example:

./version-up.sh -m

Found tag: v2.14.1 in branch 'master'
Current Revision: 192
Current Branch: master

Proposed TAG: 1.0

To apply changes manually execute the command(s):

  git tag 1.0
  git push origin 1.0

If I understand correctly, expected output should be: Proposed TAG: v3.0

Expected tag 2.14.1 but was v2.14.1... you need to adjust the script for your version tag pattern.

You may check: https://stackoverflow.com/a/5719854/349681 - How to rename git tag

@rasmusskovdk

This comment has been minimized.

Copy link

@rasmusskovdk rasmusskovdk commented Apr 8, 2021

Thank you very much. Very nice job indeed.

Do you have any thoughts on the supported versioning scheme?

I'm considering expanding the script to support "official" Semantic Versioning 2.0.0 (as found on https://semver.org/spec/v2.0.0.html).
... or at least supporting the versioning scheme we use (v1.2.3-alpha.43 should be able to up into v1.2.3-alpha.44) - which doesn't seem to be supported at the moment.

Also please consider turning this gist into a repo :D

@slmingol

This comment has been minimized.

Copy link

@slmingol slmingol commented May 8, 2021

Thank you for this script. I added a couple of echo '' to the apply condition to cleanup the output displayed when running the git --no-pager log ... cmds. Otherwise my prompt started right at the end of the last log msg it displayed.

...
...
# should we apply the changes
 if [[ "$DO_APPLY" == "1" ]]; then
     echo ''
     echo "Applying git repository version up... no push, only local tag assignment!"
     echo ''

     git tag $(compose)

     # confirm that tag applied
     git --no-pager log --pretty=format:"%h%x09%Cblue%cr%Cgreen%x09%an%Creset%x09%s%Cred%d%Creset" -n 2 --date=short | nl -w2 -s"  "
     echo ''
     echo ''
 fi
@slmingol

This comment has been minimized.

Copy link

@slmingol slmingol commented May 12, 2021

I suspect this might be a bug here where you're calculating the highest tag value:

## get highest version tag for all branches
function highest_tag(){
  local TAG=$(git tag --list 2>/dev/null | tail -n1 2>/dev/null)
  echo "$TAG"
}

I suspect this should be like so:

## get highest version tag for all branches
function highest_tag(){
  local TAG=$(git tag --list 2>/dev/null | tail -n1 2>/dev/null | sort -V)
  echo "$TAG"
}

For e.g.:

$ git tag --list | tail -10
0.0.70
0.0.71
0.0.72
0.0.73
0.0.74
0.0.75
0.0.76
0.0.77
0.0.8
0.0.9

But with my approach:

$ git tag --list | tail -10 | sort -V
0.0.8
0.0.9
0.0.70
0.0.71
0.0.72
0.0.73
0.0.74
0.0.75
0.0.76
0.0.77
@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented May 15, 2021

I suspect this might be a bug here where you're calculating the highest tag value:

Thanks @slmingol for catching it. I will update the script shortly.

@OleksandrKucherenko

This comment has been minimized.

Copy link
Owner Author

@OleksandrKucherenko OleksandrKucherenko commented Jun 9, 2021

Script updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment