Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20594

Expose parsed maven project version

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: maven-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      JENKINS-18272 introduced the POM_VERSION enviroment variable but it would be nice to also get the parsed version.

      Example:
      Version is 1.0-SNAPSHOT

      POM_VERSION = 1.0-SNAPSHOT
      POM_VERSION_MAJOR = 1
      POM_VERSION_MINOR = 0
      POM_VERSION_QUALIFIER = SNAPSHOT

        Attachments

          Issue Links

            Activity

            Show
            mmchr Mads Mohr Christensen added a comment - Pull request: https://github.com/jenkinsci/maven-plugin/pull/11
            Hide
            mmchr Mads Mohr Christensen added a comment -

            Also supported in that pull request is:

            POM_VERSION_INCREMENTAL
            POM_VERSION_NEXT_MAJOR
            POM_VERSION_NEXT_MINOR
            POM_VERSION_NEXT_INCREMENTAL
            POM_VERSION_BUILDNUMBER

            Show
            mmchr Mads Mohr Christensen added a comment - Also supported in that pull request is: POM_VERSION_INCREMENTAL POM_VERSION_NEXT_MAJOR POM_VERSION_NEXT_MINOR POM_VERSION_NEXT_INCREMENTAL POM_VERSION_BUILDNUMBER
            Hide
            kutzi kutzi added a comment -

            Is it really necessary to introduce all these fine grained env variables?
            I mean version major,minor,incremental - yeah okay.

            But NEXT_x? If someone is interested in that one, can he not simply calculate it by himself?

            What is the usecase for all this?

            Show
            kutzi kutzi added a comment - Is it really necessary to introduce all these fine grained env variables? I mean version major,minor,incremental - yeah okay. But NEXT_x? If someone is interested in that one, can he not simply calculate it by himself? What is the usecase for all this?
            Hide
            mmchr Mads Mohr Christensen added a comment -

            The use case I needed this for is a build pipeline where the initial build sets the project version to major.minor.buildnumber. This way the resulting artifact can be tested and when tests are passed, this same artifact can go into production. The idea is that every commit is a RC.

            These new variables makes it much easier to do as I can pass these new variables to the maven plugin versions "set" goal and use it directly in the build name setter plugin. In my current build I'm using a combination of maven-help-plugin and some scripting, build helper maven plugin and the versions maven plugin.

            The NEXT_x vars can be used if you want to automate release branches. First you create a release branch and then you update the development version in the develop branch. This is not really something I need, I just added the same variables as the build helper maven plugin uses in its "parse-version" goal.

            Show
            mmchr Mads Mohr Christensen added a comment - The use case I needed this for is a build pipeline where the initial build sets the project version to major.minor.buildnumber. This way the resulting artifact can be tested and when tests are passed, this same artifact can go into production. The idea is that every commit is a RC. These new variables makes it much easier to do as I can pass these new variables to the maven plugin versions "set" goal and use it directly in the build name setter plugin. In my current build I'm using a combination of maven-help-plugin and some scripting, build helper maven plugin and the versions maven plugin. The NEXT_x vars can be used if you want to automate release branches. First you create a release branch and then you update the development version in the develop branch. This is not really something I need, I just added the same variables as the build helper maven plugin uses in its "parse-version" goal.
            Hide
            mplushnikov Michail Plushnikov added a comment -

            +1 Very useful to build pipelines!

            Show
            mplushnikov Michail Plushnikov added a comment - +1 Very useful to build pipelines!
            Hide
            as_kumlali Ali Sadik Kumlali added a comment -

            +1

            POM_VERSION_MAJOR and POM_VERSION_MINOR variables would be quite useful for pipeline version. (e.g. ${POM_VERSION_MAJOR}.${POM_VERSION_MINOR}.${SVN_REVISION}.${BUILD_NUMBER} )

            Show
            as_kumlali Ali Sadik Kumlali added a comment - +1 POM_VERSION_MAJOR and POM_VERSION_MINOR variables would be quite useful for pipeline version. (e.g. ${POM_VERSION_MAJOR}.${POM_VERSION_MINOR}.${SVN_REVISION}.${BUILD_NUMBER } )
            Hide
            scanguskhan Scott MacDonald added a comment - - edited
            {POM_VERSION_MAJOR}

            .${POM_VERSION_MINOR}.${revision} is super helpful in CD, especially when using SEMVER which embeds compatibility into the version identifier based on the scope of compatibility of the work. This allows the pom to contain the software SEMVER version and be a source controlled asset completely specified by the developer making the change (whose knows whether the change is compatible or not) , while allowing CD to simply add on a unique increment# to the existing checked in major.minor to indicate a compatible increment of the developer specified major.minor compatible SEMVER version checked into the pom.xml.

            mvn version:set -DnewVersion=${POM_VERSION_MAJOR}.${POM_VERSION_MINOR}.${BUILD_NUMBER}

            with the pom be something like <version>1.0.${revision}</revision> where the major.minor is controlled via checkin by the developer making the compatible or incompatible change,and increment is pulled from CD (like git commit or jenkins build#)

            Show
            scanguskhan Scott MacDonald added a comment - - edited {POM_VERSION_MAJOR} .${POM_VERSION_MINOR}.${revision} is super helpful in CD, especially when using SEMVER which embeds compatibility into the version identifier based on the scope of compatibility of the work. This allows the pom to contain the software SEMVER version and be a source controlled asset completely specified by the developer making the change (whose knows whether the change is compatible or not) , while allowing CD to simply add on a unique increment# to the existing checked in major.minor to indicate a compatible increment of the developer specified major.minor compatible SEMVER version checked into the pom.xml. mvn version:set -DnewVersion=${POM_VERSION_MAJOR}.${POM_VERSION_MINOR}.${BUILD_NUMBER} with the pom be something like <version>1.0.${revision}</revision> where the major.minor is controlled via checkin by the developer making the compatible or incompatible change,and increment is pulled from CD (like git commit or jenkins build#)

              People

              • Assignee:
                Unassigned
                Reporter:
                mmchr Mads Mohr Christensen
              • Votes:
                5 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: