allow calculating the version based on number of commit since closest ancestor tag

[radai-rosenblatt]

i would like for every CI build on my project to create a non-snapshot release.

IIUC, that currently means creating a tag on every single commit which (no matter if done manually or by the plugin) seems combersome to me.

i'd like to propose the option of calculating the version string as "version from latest tag" + [number of commits since tag] (as patch version)

so if i have commit hash H1 with tag 1.2.3, commit H2 would be 1.2.4, H3 would be 1.2.5 etc until a new tag is created (to mark the next major/minor release)

[vivin]

The patch version should have nothing to do with the number of commits since the last tag created. Furthermore, this can lead to very non-obvious behavior.

Let's say at commit H1, the version is, as you said, 1.2.3. The behavior would be surprising to say the least, if after two commits, the plugin reports that the version is 1.2.5, but creating a tag uses the version 1.2.4 (which would be the next patch version).

This sort of functionality would be better implemented via pre-release identifiers. Something like this should work:

preRelease {    
    startingVersion = "c0"

    bump = {
        String latestTagOnBranch = "git describe --abbrev=0 --tags".execute().text.trim()
        String numCommits = "git rev-list ${latestTagOnBranch}..HEAD --count".execute().text.trim()
        "c${numCommits}"
    }
}

Keep in mind though that this is not a good versioning scheme because it can be quite confusing. The pre-release version, being completely dependent on the number of commits, can change drastically if you rebase or squash commits, and can also cause you to potentially overwrite existing versions.

[radai-rosenblatt]

im assuming no history-rewriting on the release branch (which would result in the version repeating itself, as youve said).

also its fairly trivial to protect against dup releases downstream of the CI pipeline (for example, bintray by default refuses to update a release thats already been published)

the potential for devs creating a wrong tag exists already, i think? whats preventing me from accidentally tagging 0.0.1 anywhere?

the motivation behind my request is i want the absolute minimum effort on the part of devs - every commit to the repo results in a release being created. i also dont plan on working with snapshots or pre-releases.

im also trying to avoid the CI server modifying the source repository (by creating a tag, for example), because then i'd need to prevent the CI from reacting to its own changes, which just looks like complication to me.

right now the easiest way to do that would be follow up every single commit with a tag, which is extra work for devs.

is there another way of accomplishing this?

[vivin]

Yes, it is true that you can create a duplicate tag. But you have to be rather explicit about it. The feature you are suggesting will actually make this more likely and on accident; it's also non-intuitive and surprising behavior. Also, as I said, it violates semver principles as the patch version has nothing to do with the number of commits. There is also ambiguity; there would be no way to distinguish release 1.2.5 that is 5 commits from 1.2.0 from version 1.2.5 that is a patch bump from 1.2.4.

As I mentioned earlier, you can kind of do this with pre-release versioning if you want. But I don't think I will be supporting the ability to modify the patch version in a manner inconsistent with the semver specification.

On Nov 1, 2017 7:42 PM, "Radai Rosenblatt" notifications@github.com wrote:

im assuming no history-rewriting on the release branch (which would result in the version repeating itself, as youve said).

also its fairly trivial to protect against dup releases downstream of the CI pipeline (for example, bintray by default refuses to update a release thats already been published)

the potential for devs creating a wrong tag exists already, i think? whats preventing me from accidentally tagging 0.0.1 anywhere?

the motivation behind my request is i want the absolute minimum effort on the part of devs - every commit to the repo results in a release being created. i also dont plan on working with snapshots or pre-releases.

im also trying to avoid the CI server modifying the source repository (by creating a tag, for example), because then i'd need to prevent the CI from reacting to its own changes, which just looks like complication to me.

right now the easiest way to do that would be follow up every single commit with a tag, which is extra work for devs.

is there another way of accomplishing this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vivin/gradle-semantic-build-versioning/issues/86#issuecomment-341301620, or mute the thread https://github.com/notifications/unsubscribe-auth/AADbHhtsqUWOtsSvX6aJJwVBXjEpUe7eks5sySwQgaJpZM4QNrja .

[vivin]

I'm also not sure why you would want to avoid creating tags on the source repository; that's essentially the only way the plugin can function, and the plugin itself can create and push that tag for you.

This plugin calculates the version based on the previous tag, and the kind of version manipulation that you want to do; it has nothing to do with how many commits have been made since the latest tag (or the starting version).

Right now you can actually do what you want to do if you build a release version on your CI server and push tags, because the default behavior is to bump patch.