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

reenable "ability to let maven decide the versioning"

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • m2release-plugin
    • None

      It kind of feels odd to remove a useful feature just because the information is used for a tooltip in the UI.
      please reenable the option "let maven decide the versioning"" removed in 0.8.0

      without this option one is not able to have a workaround to define different versions for each module.

          [JENKINS-11466] reenable "ability to let maven decide the versioning"

          James Nord added a comment - - edited

          letting maven decide the version won't be coming back (and its not just about a UI tooltip).

          The ability to set a version for each module is different.

          Out of curiosity what is the use case for having multiple different versions inside one reactor build?

          James Nord added a comment - - edited letting maven decide the version won't be coming back (and its not just about a UI tooltip). The ability to set a version for each module is different. Out of curiosity what is the use case for having multiple different versions inside one reactor build?

          sorry for all the duplicates, JIRA was filing every time I tried to create the issue.

          the thing is that I know one team in my company is using exactly this feature when doing a multimodule release (more then 20 modules) for eclipse projects with tycho. But I'm not really into the whole OSGI an eclipse artifacts, but they thought its really important to them...

          Dominik Bartholdi added a comment - sorry for all the duplicates, JIRA was filing every time I tried to create the issue. the thing is that I know one team in my company is using exactly this feature when doing a multimodule release (more then 20 modules) for eclipse projects with tycho. But I'm not really into the whole OSGI an eclipse artifacts, but they thought its really important to them...

          I am relying heavily on the 'let maven decide the version' feature. Please re-enable it.

          What was the reason for removing it, if it wasn't just for the UI tooltip? I don't see a corresponding jira item for this change.

          For now, I'll roll back to my previous version of m2release.

          Marcel Schutte added a comment - I am relying heavily on the 'let maven decide the version' feature. Please re-enable it. What was the reason for removing it, if it wasn't just for the UI tooltip? I don't see a corresponding jira item for this change. For now, I'll roll back to my previous version of m2release.

          Allen Lau added a comment -

          I rely on it for releasing patched binaries.
          So each module usually have a different version number than the parent/aggregate pom that the jenkins job is triggering.

          Allen Lau added a comment - I rely on it for releasing patched binaries. So each module usually have a different version number than the parent/aggregate pom that the jenkins job is triggering.

          jason c added a comment -

          I second this, the automatic version numbering is a MAJOR feature of the maven release plugin and I'm apparently not the only one that is of the opinion that this plugin is essentially broken without it.

          jason c added a comment - I second this, the automatic version numbering is a MAJOR feature of the maven release plugin and I'm apparently not the only one that is of the opinion that this plugin is essentially broken without it.

          James Nord added a comment -

          it is needed for the current integration with Nexus - so you can find the version that has been deployed.
          It's also for some stuff that's in the pipeline

          If you have not changed versions / added any modules since the last build then the "specify for every module" (which will be re-instated) will give you exactly the same result at the expense of a larger UI screen.

          James Nord added a comment - it is needed for the current integration with Nexus - so you can find the version that has been deployed. It's also for some stuff that's in the pipeline If you have not changed versions / added any modules since the last build then the "specify for every module" (which will be re-instated) will give you exactly the same result at the expense of a larger UI screen.

          A little late to the party...I was thinking of using your plugin to replace a perl scripted process that injected version numbers via expect, but without the ability to accept defaults, I can't automate a release of a pipeline of 80 artifacts.

          I agree that a reactor project with varying versions in sub-modules is odd, but that shouldn't mean the whole accept default use-case is removed. Should it? I agree with jason c, this is a MAJOR feature. Did all the users of this feature simply not upgrade and are using version 0.7.1 ?

          James Levinson added a comment - A little late to the party...I was thinking of using your plugin to replace a perl scripted process that injected version numbers via expect, but without the ability to accept defaults, I can't automate a release of a pipeline of 80 artifacts. I agree that a reactor project with varying versions in sub-modules is odd, but that shouldn't mean the whole accept default use-case is removed. Should it? I agree with jason c, this is a MAJOR feature. Did all the users of this feature simply not upgrade and are using version 0.7.1 ?

          Dan H added a comment -

          What wally removed this and why? We have been happily using this feature for years without issue. To get around this bug we have no choice but to revert to a prior version of the plug-in.

          Dan H added a comment - What wally removed this and why? We have been happily using this feature for years without issue. To get around this bug we have no choice but to revert to a prior version of the plug-in.

          Cuong Tran added a comment -

          Is there a workaround for this?

          Cuong Tran added a comment - Is there a workaround for this?

          I would like to have this back too. When we are talking about OSGi and semantic versioning it is always possible to have more than one version inside the same reactor. this is a fact !

          Cristiano Gavião added a comment - I would like to have this back too. When we are talking about OSGi and semantic versioning it is always possible to have more than one version inside the same reactor. this is a fact !

            Unassigned Unassigned
            domi Dominik Bartholdi
            Votes:
            8 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: