Running this tool on any release branch, that is below master.
/jx-release-version-linux
failed to get new version strconv.ParseInt: parsing "51.2": invalid syntax

If I use --same-release, it works on this branch.

Running this tool on master branch, which does not have any release tags
./jx-release-version-linux
failed to get new version error fetching tags: exit status 1

The README needs to be updated for the new build automation tools that have been added support for lately.

feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).

• source: conventionalcommits specification

Expected behavior:

git commit --am 'feat(api): adds cool feature

Should increment MINOR version when jx-release-version run. (e.g: 0.0.0 -> 0.1.0)

Actual behavior:

Only the PATCH version is incremented. (e.g: 0.0.0 -> 0.0.1)

Note:

Removing the scope from the git commit message does increment MINOR version correctly.

git commit --am 'feat: adds cool feature to api

version: 2.5.1
source: ghcr.io/jenkins-x/jx-release-version:2.5.1

https://github.com/renovatebot/renovate

Easy to install, configure and use, it could take care of Dockerfile and golang dependencies udpates.

I see a lot of changes have been done in this project since I last was here.
Good to see it still is alive and under maintenance.

I cannot see it is no longer possible to use the version in the file as a base, while incrementing from git tag.
We are using automatic versioning, so the build file contains only the base version.

Standing on RELEASE_A branch, with version 1.5.0 in build.gradle
The latest release in git is v1.5.5

Though master has the version 1.6.0 in build.gradle.
The latest release on master in git is v1.6.3.

This tools gives me the release 1.6.4. Though I am interested in getting 1.5.6.

Is this still possible, or has that feature been removed?
After the rewrite it seems gone. There was a flag to indicate to use the same version where you where standing.

"same-release", false, "for support old releases: for example 7.0.x and tag for new release 7.1.x already exist, with -same-release argument next version from 7.0.x will be returned.

What is strange is if I use -previous-release, I get the next version I want.
jx-release-version -previous-version from-tag:v1.5
This will get me the next v1.5 release, 1.5.6. PS! The latest git tag is v1.5.5, so should this not output 1.5.5?

What I really want is not needing to supply the v1.5 format. Using the base version in build.gradle would be better.

Why was this same-release feature removed? No one who needs to get a next version on an old release branch?

Hi! I'm using jx-release-version version 2.4.2 on ubuntu to get next tag and push to Gitlab. It's been working fine for me but suddenly I started seeing this error:

FATAL: Failed to bump version using "auto": object not found

I've never encountered this error before and I'm not sure why it's happening. Here is the sequence of commands I run:

git fetch origin 'refs/tags/*:refs/tags/*'
tag=$(./jx-release-version)

see also #20

We have moved many of the variables in build.gradle over to gradle.properties, this includes the version.
This tool should support checking for version in gradle.properties, if there is no version in build.gradle.

Update Makefile adding:

VERSION:
	echo "foo"

Run the jx-release-version utility

jx-release-version
panic: runtime error: index out of range                                                                                                                                                                    

goroutine 1 [running]:
main.getVersion(0x0, 0x6ef703, 0x1, 0x0, 0x0, 0x0, 0x0, 0x6f0010, 0x5, 0x726680, ...)
        /home/foo/go/src/github.com/jenkins-x/jx-release-version/main.go:92 +0xd92
main.getNewVersionFromTag(0x0, 0x6ef703, 0x1, 0x0, 0x0, 0x0, 0x0, 0x10, 0xc420096c10, 0x0, ...)
        /home/foo/go/src/github.com/jenkins-x/jx-release-version/main.go:244 +0x149
main.main()
        /home/foo/go/src/github.com/jenkins-x/jx-release-version/main.go:52 +0x202

There is something peculiar with the releases since v1.0.17. They are tagged differently somehow, and are not on master git history.

The last release that can be seen on master with git log is v1.0.17

Support for cmake by reading the version from CMakeLists.txt

project(project VERSION 2.1 LANGUAGES CXX)

RegEx for getting the version:

project\\s*\\(([^\\s]+)\\s+VERSION\\s+([.\\d]+).*\\)

This tool worked on a cmake project, but only master. For any release branch it output 0.0.1, even if I used --same-release. If I create a Makefile here with the version in CMakeLists.txt it works.

The current code for finding the version in a setup.py file, only accepts single quotes around the version field.
I believe the code is on this line

The fix might be to update the regex and add tests:
I'm sorry I don't write go code often. This is my best guess.

regexp.MustCompile(`setup\((.|\n)*version\s*=\s*['"](\d|\.)*['"]([^\)]|\n)*\)`)

To recreate the error:

jx-release-version --version
Version 2.5.0 - Revision 2ef4e951f50ed149e8b103e3d08ae1a01d848489 - Date Mon Sep 20 11:21:35 UTC 2021%

My setup.py file:

from setuptools import setup, find_packages

setup(
    name="example",
    version="0.0.1",
    author="My Name",
    author_email="[email protected]",
)

Error:

FATAL: Failed to read previous version using "from-file:setup.py": setup call not found in file [REMOVED PATH]/setup.py

The fix is to change the double quotes to single quotes around the version string.

from setuptools import setup, find_packages

setup(
    name="example",
    version='0.0.1',
    author="My Name",
    author_email="[email protected]",
)

This issue is not urgent.
It's a nice to have to add flexibility around which quote (single or double) is used primarily in the codebase.

I test the plugin from [2.6.3] until [2.6.6]

I customize in jx3 mi next version with this code because I don't want the "v" in the name of tag:

         - image: ghcr.io/jenkins-x/jx-release-version:2.6.6
          name: my-nextversion-master-minor
          resources: {}
          script: |
            #!/usr/bin/env sh
            set -x
            if [ "$PULL_BASE_REF" == "master" ] || [ "$PULL_BASE_REF" == "main" ]; then
                jx-release-version -next-version=increment:minor --debug --tag --tag-prefix="" > VERSION
            else
                jx-release-version -next-version=increment:patch --debug --tag --tag-prefix="" > VERSION
            fi
            cat VERSION

But I received a "false" error in the push process:

jx-release-version '-next-version=increment:patch' --debug --tag '--tag-prefix='
DEBUG: jx-release-version 2.6.6-dev+4b57fec running in debug mode in /workspace/source
DEBUG: Using "auto" version reader (with "")
DEBUG: Trying to read the previous version from the git tags first...
DEBUG: Found 55 semver tags with pattern ""
DEBUG: Previous version: 1.7.3
DEBUG: Using "increment" version bumper (with "patch")
DEBUG: Incrementing patch component
DEBUG: Next version: 1.7.4
DEBUG: git tag -a 1.7.4 -m "Release version 1.7.4"
DEBUG: git push --tags
FATAL: Failed to tag using version 1.7.4: failed to push tags to origin: authentication required
cat VERSION
1.7.4

But in my github repo the tag is correctly uploaded:

Why the FATAL error?

Where there are no new commits checked in since last release version, the returned version should be the same as the last tagged release.
Otherwise you risk releasing again on the same commit if you start a new build in the CI.

Premise: The base version is 1.2.0, and the latest release tag is v1.2.8 at git HEAD.
Running jx-release-version should return 1.2.8 and not 1.2.9.

Issue

The issue happens with squash message when it has colon (":") , the conventional commit gets ignored when it has major, minor or breaking change.

example:
current version: 1.0.0
PR with 3 commits 3 :

feat!: new feature 
chore: blabla
fix: fix x bug 

Squand-and-Merge:
Title:

feat!: new feature

Squash-message:

The new feature will add the following: 
- x
- y
- z
- in USD:CAD; will be changed.

#Expected
The version will bumped from 1.0.0 -> 2.0.0
but the version bumped to 1.0.1

Debug log:

calculate version from commit messages
DEBUG: jx-release-version 2.6.10-dev+cb5085f running in debug mode in /workspace/source
DEBUG: Using "auto" version reader (with "")
DEBUG: Trying to read the previous version from the git tags first...
DEBUG: Skipping non-semver tag "hello-world1-0.0.4" (Invalid Semantic Version)
DEBUG: Skipping non-semver tag "hello-world10.0.4" (Invalid Semantic Version)
DEBUG: Found 73 semver tags with pattern ""
DEBUG: Previous version: 24.0.1
DEBUG: Using "auto" version bumper (with "")
DEBUG: Trying to bump the version using semantic release first...
DEBUG: Previous version tag commit is 6dfbcde58433b28249a515ac95db055afef7316a
DEBUG: Iterating over all commits since 2023-12-07 13:51:11 +0000 +0000
DEBUG: Checking commit 7343d8f58cb0974c80b5f31a6d39e8a75cedd4c4 with message chore: add variables
DEBUG: Parsing commit 7343d8f58cb0974c80b5f31a6d39e8a75cedd4c4
DEBUG: Checking commit 1f717c2c1cc91f24aeeedc39501645ed32866bcc with message feat!: [BQ-627] [Fundamentals Peers] Apply entities permissioning (#60)

When the permissioning system was introduced on the universe, we automatically had permissions applied to all our FUN APIs.

##### Before
What we didn't took into account is that currently, in order to get a company peers we get the top 10 entities (based on the known filter/sorting criterias) and we apply permissions on the top 10 filtered.
ex: if a client is only enabled to XETRA exchange and he will search for APC:DE, we:
- get the top 10 entities worldwide
- out of those top 10 entities we keep only those that have instruments on XETRA

##### After
Instead of applying permissions on the top 10 peers retrieved for the requested entity, first get the entities to which the user is permissioned and get top 10 out of the permissioned ones.
DEBUG: Parsing commit 1f717c2c1cc91f24aeeedc39501645ed32866bcc
DEBUG: Skipping non-conventional commit 1f717c2c1cc91f24aeeedc39501645ed32866bcc
DEBUG: Summary of conventional commits since 2023-12-07 13:51:11 +0000 +0000: semantic.conventionalCommitsSummary{conventionalCommitsCount:1, types:map[string]bool{"chore":true}, breakingChanges:false}
DEBUG: Incrementing patch component
DEBUG: Next version: 24.0.2
run with options -tag
DEBUG: jx-release-version 2.6.10-dev+cb5085f running in debug mode in /workspace/source
DEBUG: Using "auto" version reader (with "")
DEBUG: Trying to read the previous version from the git tags first...
DEBUG: Skipping non-semver tag "hello-world1-0.0.4" (Invalid Semantic Version)
DEBUG: Skipping non-semver tag "hello-world10.0.4" (Invalid Semantic Version)
DEBUG: Found 73 semver tags with pattern ""
DEBUG: Previous version: 24.0.1
DEBUG: Using "manual" version bumper (with "24.0.2")
DEBUG: Using manual version 24.0.2
DEBUG: Next version: 24.0.2
DEBUG: git tag -a v24.0.2 -m "Release version v24.0.2"
DEBUG: git push --tags
24.0.2version 24.0.2 is created

this is really an awesome tool!
We use it outside of jenkins-x in a normal jenkins installation where we install it as a 'custom tool'. But now we started to see an issue on some of our builds, where it fails to resolve the next version unfortunate its a bit hard to debug the issue.

All I currently get is:
failed to get new version error fetching tags: %vexit status 128

My guess is that it does not work for some git authentication issues. Therefore I tried to call it with GIT_ASKPASS (using this lib: https://github.com/imod/jenkins-git-askpass-pipeline-lib) - one point to mention might also be that we use the bitbucket "multibranch plugin", there only https is available to fetch from the git remote.

@rawlingsj it would be very very cool, if you could help my out here :)

Support Gradle with reading the version from either build.gradle or gradle.properties.

It is a simple property and should be easy to get, but it can be stored in either build.gradle or gradle.properties

version = 1.0

This tool worked on a gradle project, but only on master branch. For any release branch it output 0.0.1 if I used --same-release, and without --same-release I got an error:
failed to get new version strconv.ParseInt: parsing "51.2": invalid syntax

Have version 1.5.0 in build.gradle

> jx-release-version -previous-version from-file
1.5.1

> jx-release-version -next-version from-file
1.5.0

Is this the alternate universe where things are reversed?

On branch master, where the latest git tag is v1.6.3

> jx-release-version -next-version
1.6.4
> jx-release-version -previous-version from-tag
1.6.4

There is no previous tag v1.6.4
Expected output:
1.6.4 and 1.6.3

If your project is new or has no existing git tags then running jx-release-version will return a default version of 0.0.1

Why not instead use the base version?
When no existing tags exists and the base version is 1.0.0, then jx-release-version should return a version of 1.0.0

It does not make sense to return 0.0.1 for the first release version if the base version is set to 1.0.0

Support for automake by reading the version from configure.ac

AC_INIT(project, 1.2.18, [email protected])

RegEx for getting the version:

AC_INIT\\s*\\(([^\\s]+),\\s*([.\\d]+).*\\)

This tool worked on a automake project, but only master. For any release branch it output 0.0.1, even if I used --same-release. If I create a Makefile here with the version in configure.ac it works.

If running automake then it will generate a Makefile that will work with jx-release-version.

./autogen.sh
./configure

That is a workaround, but the best solution would be to read the base version from configure.ac.

It would be great with support for other version syntax than major.minor.patch. For example major.increment or just increment.

Would be a great support version bump based on Conventional Commits.

Our example docker images are being generated starting with 7 because the versions of our tags are incrementing from 7.0.x. But this is confusing as our pom says 1.0.0:

AlfrescoArchive/example-runtime-bundle@ae6ec8f#diff-600376dffeb79835ede4a0b285078036

The reason seems to be that in the past our pom.xml did say 7.0.0 and we then moved our version number down. However we can't go back to 1.0.x as jx-release-version won't let us go backwards.

What can we do on this? Would a non-semantic version be possible? The trouble is we can't really move our versions forwards as they've already gone further forwards than we should've let them go.

Hello,

We have some repos that work on NodeJS, and then we use a package.json to declare our versions.
I need to, when a build is running, that this build update the version into my package.json.

Then when i launch a build => he incremente and add a new version into package.json ==> then create a release with this version for github.

Do you think its possible ?

I use AKS cluster with jenkins-x v2

Thanks for all

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

https://github.com/jenkins-x-plugins/jx-release-version/blob/a4539cf44b6d206c7ce3fb2340e240f2760dfcfe/hack/github-actions-entrypoint.sh#LL4C7-L4C7

This project needs a CONTRIBUTION.md, how to contribute.

1. How to get and install the go tools
   https://golang.org/doc/install#install

2. How to build
   Running make complains about missing the very tool I am trying to build
   make: jx-release-version: Command not found
   And go test -v complains about missing packages.

I managed to build running make after creating synlinks to the vendor directories under /home/username/go/src.

$ jx-release-version -version
Version 2.5.2 - Revision 779b128862773a5bab71596ded8b5653759c8910 - Date Wed May 25 06:47:30 UTC 2022

`
4.0.0

<groupId>io.example</groupId>
<artifactId>example</artifactId>
<version>1.0-0-SNAPSHOT</version>
<packaging>pom</packaging>

$ jx-release-version -previous-version=from-file --debug

DEBUG: jx-release-version 2.5.2 running in debug mode in /home/${user}/${path}/template_java-8 DEBUG: Using "from-file" version reader (with "") DEBUG: Adding file /home/${user}/${path}/template_java-8/pom.xml as a candidate to read version using maven POM reader DEBUG: Reading version from file /home/${user}/${path}/template_java-8/pom.xml using reader maven POM DEBUG: using path /home/${user}/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin DEBUG: Maven is installed into path /usr/bin/mvn DEBUG: Found version WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release 1.0-0-SNAPSHOT FATAL: Failed to read previous version using "from-file": Invalid Semantic Version

Executing jx-release-version.exe -version on Windows 10 prints blank version info:

Version:
Git Tag:
Build Date:

This is with v1.0.42.

Hi ,

I'm using jx-release-version binary to create tag in github but even after setting GITHUB_AUTH_TOKEN environment it asks for credentials.

./jx-release-version -debug

available environment:
OLDPWD=/home/ubuntu/jenkins-runner
SSH_TTY=/dev/pts/0
USER=ubuntu
MAIL=/var/mail/ubuntu
PATH=/home/ubuntu/bin:/home/ubuntu/.local/bin:JAVA_HOME/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/ubuntu/bin:/usr/lib/jvm/jdk-12.0.2/bin:/home/ubuntu/bin:/usr/lib/jvm/jdk-12.0.2/bin
GITHUB_AUTH_TOKEN=XXXXXXXXXXXXX
PWD=/home/ubuntu/jenkins-runner/example-flask
JAVA_HOME=/usr/lib/jvm/jdk-12.0.2
LANG=en_US.UTF-8
SHLVL=1
HOME=/home/ubuntu
LOGNAME=ubuntu
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
LC_CTYPE=UTF-8
_=./jx-release-version
Username for 'https://github.com':