Skip to end of metadata
Go to start of metadata

Plugin Information

View Release on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin is up for adoption. Want to help improve this plugin? Click here to learn more!

This plugin adds the ability to wrap your job with pre- and post- build steps which are only executed when a manual release build is triggered.

Additional plugin integration

Supports the Dashboard View with the Recent Releases portlet and the Promoted Builds Plugin with the Release build condition.

Configure the job to enable releasing

On the job configuration page, enable the release build configuration under the Build Wrapper heading and add your required release version template string, release parameters, pre and post build steps that you need to complete a release.

Release Version Template

The release version template was added in version 1.7 of the release plugin.  This parameter lets you define how the release plugin identifies the release of the project.  This is done by building a parameter based template which is resolved at release time to a fully resolved string.  For instance, the template can be: Release: ${releaseVersion}.  This will instruct the release plugin to use the value of the parameter name releaseVersion to come up with the fully identifying string which will then be used as a description of the release build and as a tooltip on the release build icon on the historical build list.

Release Parameters

The release parameters let you define various parameters that are presented to the user when a release is requested.  The list of available parameter types are the same as those available in the parameterized build option for Jenkins.

Build Steps

The build steps section is used to define arbitrary actions to run before and after the standard job build steps run. These are the same build steps offered as the build steps available in the free style job type.

In my experience, a release build typically requires pre-build steps of validating the project is releasable and bumping the version to the release version. After the build runs as usual, the post build steps are labeling the codebase and bumping the version to the next development version.

Executing a release

To run a release, click the Release icon from the job home page. This will bring you to the release details page where you will be prompted to fill in any parameters that you have defined (or the default RELEASE_VERSION and DEVELOPMENT_VERSION if there were no parameters defined).  As seen above, these values are then available at job execution time in both the pre and post release steps as well as the normal build steps. Finally, click the schedule release build and the job is scheduled to run immediately, now including the execution of the pre and post build steps.

Viewing results

Once the build is complete, the release plugin automatically locks the build, preventing it from being automatically deleted and adds a release icon denoting it as a release build.

Supported Job Types

 The release plugin supports the Maven2 and Free Style Job type

Recent Releases Portlet

The release plugin contributes a recent releases portlet that can be used in a Dashboard View

This portlet shows the 5 most recent release builds in normal mode with a link that brings you to the build page and the version string.
In the maximized mode, it shows the 50 most recent builds with additional detail.  Additionally it offers an rss feed while in the maximized mode so that you can get notified of all release builds or all failing release builds.

Version History

Version 2.10.1 (Mar 13, 2018)

  • No user-visible changes
  • Developer: Upgrade the plugin to the latest plugin POM

Version 2.10 (Jan 22, 2018)

Version 2.9 (Dec 08, 2017)

  • JENKINS-26895 - Prevent exception when Dashboard View plugin is not installed
  • PR #27 - Update Maven Plugin dependency to 3.0, cleanup other dependencies

Version 2.8 (June 27, 2017)

Version 2.7 (Apr 08, 2017)

Version 2.6.1 (10/13/2016)

  • JENKINS-20797 - In addition to the fix in 2.6, schedule new release builds with the actual User Cause widely supported by plugins

Version 2.6 (09/29/2016)

Oleg Nenashev is a temporary maintainer.

  • Core dependency has been updated from 1.481 to 1.609.3 LTS (justification)
  • JENKINS-34996 Fix the compatibility with Jenkins cores containing the SECURITY-170 fix (pull request #17, thanks to Antonio Muñiz)
  • JENKINS-11176 "If the build is a release build" promotion criteria was broken due to the improper descriptor handling in the plugin (pull request #15, thanks to Allan Burdajewicz)
  • JENKINS-28132 "Release" permission is now implied by Jenkins Administer permission (pull request #16, thanks to aprueller)
  • JENKINS-20797 Recent Releases Portlet should support extraction of users from the new "triggered by user" cause being used in Jenkins 1.427+ (pull request #18)
  • PR #18 Recent Releases Portlet should not create new users for non-existent usernames when rendering the output page (pull request #18)
  • Cleanup of minor issues discovered by FindBugs (pull request #19)

Version 2.5.4 (10/26/2015)

  • JENKINS-31159 Fix postMatrixBuildSteps (Pull request #13, thanks to Fiouz)

Version 2.5.3 (4/25/2015)

  • JENKINS-27722 upgrade to the release plugin has left the plugin broken (Pull request #12, thanks to glenritchie)
  • Change so that now you can select Publisher and Builders in the (release) build steps (Pull request #11, thanks to glenritchie)
  • Small translation fix (Pull request #10, thanks to Batmat)
  • Add two custom view job filters "All Release Jobs" and "Release Jobs" (Pull request #9, thanks to fritaly)
  • Define a new RELEASE permission (Pull request #8, thanks to fritaly)
    • BEWARE: You need to adapt your permissions so that users still see the release button
  • Set the description for the parent of a matrix build (Pull request #7, thanks to fritaly)
  • Add ability to run steps before/after all matrix configurations

Version 2.4.1 (9/27/2013)

  • Don't display release action in matrix configuration

Version 2.4 (8/04/2013)

Version 2.3 (9/20/2012)

  • JENKINS-13422 Added release button column
  • Use package.png instead of package.gif to have transparent icons
  • Fixed release link being shown when project was disabled

Version 2.2 (9/13/2011)

  • Disabled auto-refresh when triggering a new release (thanks rseguy)
  • JENKINS-9705 Option to override regular build parameters during release

Version 2.1 (3/13/2011)

  • JENKINS-8816 Wrapped each build steps list in a f:block which seems to correct the drag and drop behavior
  • JENKINS-8829 Create permalinks for the latest release and latest successful release builds
  • Added i8n for promotion support
  • Added German translations

Version 2.0 (2/15/2011)

  • Migrated to Jenkins
  • If release build result is not at least unstable, then don't keep build forever.
  • Expand release version template using build variables as well as release parameters
  • Add support for the promoted build plugin to add a condition that the build must be a release build
  • Show all previous release parameters when scheduling a release build
  • Add post successful build steps and post failed build steps
  • Prefill release parameters with previous release builds parameters (supports text field, checkbox & select list (drop-down list) input types)

Version 1.10 (7/21/2010)

  • Added new checkbox on job config page to allow the disabling of the automated marking of the build as keep forever
  • Fixed issue where if you had overlapping parameter names defined as release and build parameters, the default build parameter values were being used to resolve the release version template instead of the release parameter values.

Version 1.9 (11/15/2009)

  • Fixed issue where release plugin would prevent Jenkins from starting if dashboard view plugin was not installed (4845)
  • Fixed issue where recent releases portlet would throw NullPointer if a build was active

Version 1.8 (10/13/2009)

  • Added support for Dashboard View plugin by adding Recent Releases portlet

Version 1.7 (08/30/2009)

  •  After sleeping on it, changed the implementation to use the release version template so that parameters types don't have to be aware of the release plugin in order to be used as a release version string.

Version 1.6 (08/29/2009)

  • Added new Release String Parameter that, when configured as a release parameter, will be used as the release value and the plugin will then set description and tooltip. (4022)

Version 1.5 (08/06/2009)

  • Changed form submission to use post instead of get. File upload parameters work now.

Version 1.4 (05/16/2009)

  • Fixed regression issue introducing release parameters (3690)

Version 1.3 (05/11/2009)

  • Fixed regression due to maven plugin change (3628)

Version 1.2 (05/1/2009)

  • Added support for user supplied release parameters leveraging Jenkins' parameter capability (3370)

Version 1.1 (03/26/2009)

  • Add permissions on triggering a release
  • Fixed issue where parameters were not being resolved
  • Captured release parameters as build parameters which can now be viewed via build parameters link

Version 1.0 (02/10/2009)

  • Initial release 


  1. I believe this could be useful also for multi-configuration (matrix) projects.
    Thanks for the plug-in

  2. Nice plugin,

    Some feedback:

    - It would be nice to have the possibility to configure security issues about the Release button independent from the Build button.

    - The release process may not contain the normal build process but a different one (maybe add a button to disable the normal build process during release).

    thanks for the plugin

    1. I took a brief look at the security a while ago but I didn't see a way for plugins to add new permissions.  Do you have any pointers on this?

      If the release process doesn't contain the normal build process, then you could just create a new job that contains exactly what your release steps are?  This release plugin's value is that it is taking advantage of your job configuration including all the reporting plugins that you may have configured.

  3. How do I provide more parameters?  These are my steps below:

    release:prepare -DscmCommentPrefix=[add:${ISSUE}] -DreleaseVersion=${RELEASE_VERSION} -DdevelopmentVersion=${DEVELOPMENT_VERSION} -Dtag=REL-${RELEASE_VERSION}
    release:branch -DbranchName=rel-${DEVELOPMENT_VERSION} -DscmCommentPrefix=[add:${ISSUE}] -DupdateWorkingCopyVersions=false
    I need to parametrized the ${ISSUE}
    value but it is not working. Our SVN enforces strict comment standards due to which we need to provide an parametrized value

    1. The plugin only supports 2 input fields, development version and release version.  Could you perhaps use a comment called branching for development of rel-${DEVELOPMENT_VERSION}

      1. The best would be if this plugin follows the maven-release plugin parameter types.  I like the way Continuum implemented it.

      2. How about asking for the comment at runtime?  similarly like asking for the release version and development version.

    1. I think that the Sonatype guys are working on Maven2 release supportfor Hudson. 

  4. Unknown User (huimies)

    This plugin is great, but one feature would make it awesome.

    If changes would be collected from last release build to current release build so that in changes view you could see a complete changelog between releases.

    1. This would be very cool and something that I would be interested in as well.  I will see if there is some way I can pass the date Hudson uses to generate a change log.

      1. I took a quick look at how the SCM plugins generate the history.  They call the build.getPreviousBuild method and ask for the build date.  I would have to override the build class (or decorate it) in order for release plugin to inject a different build as the previous build.  So it won't be too straightforward and could impact the stability of this plugin (as happened earlier) if I go down this path.

  5. One more problem I found:

    When you have the Descriptor Setting plugin enabled for the job, it overrides the Release plugin description.  Would be nice if the Release plugin sets the description at the very end after the descriptor setting plugin has completed its job.

    1. This might be a little tricky as the plugin is a BuildWrapper which Hudson core runs before the post build stuff.  Also, I am not sure how Hudson orders plugins that execute during the same phase so it might not be guaranteed to get the description set properly.  Maybe it would be better for the description plugin to not remove an existing description if one exists but just append its description after the existing one if any.

  6. Unknown User (

    I have a slight problem. I'm running Hudson 1.292 inside of tomcat 5.5 as a Windows Service (sad) and trying use the release plugin. Here's the problem:

    I have targets in pre and post release that I want to use


    The problem is this my version property for the ant build gets set literally to


    and not 2.1.1 or similar.

  7. What would it involve to modify this plugin so the list of release steps matches the actions from the promotion plugin. The promotion plugin has a lot more actions such as svn tag, scp etc.. Would be great to have these for pre and post release steps. I'd be open to making the modifications

  8. What would it involve to modify this plugin so the list of release steps matches the actions from the promotion plugin. The promotion plugin has a lot more actions such as svn tag, scp etc.. Would be great to have these for pre and post release steps. I'd be open to making the modifications

    1. Sorry for not noticing this post for a long time.

      I have not used the promotion plugin and just quickly installed it and took a look around.  I would think that it should not be too hard to get the larger list of actions that the promoted plugin offers (without taking a look at it).  I'd be happy for you to contribute to the plugin in this manner.  I think it would be a nice additional feature.

  9. Unknown User (

    Hi Peter,

    While using your plugin, I was wondering would it be possible to make the parameters available to fields outside of the build properties.

    i.e. Since this plugin is aimed at manual release, I want to be able to manually specify the CVS TAG to check out and build. But when I specify my RELEASE_VERSION Parameter in the CVS tag field in Source Code Management, it would throw an errors since it doesn't recognize the Parameter value.

    My workaround would be to instead run CVS in Execution shell, and use RELEASE_VERSION as the check out there. But it would be much nice if the Release Parameters could be integrated with the standard Hudson Source Code Management.


    1. I would think there is some way to do this.  Have you looked at the Hudson source code to see how this might be possible.  I'm pretty sure this would require a change to the Hudson core to accomplish.

  10. Unknown User (lorand.somogyi)

    I'm preparing Hudson for our team, and I'm really impressed by the features and plugins.

    I was about to create a new plugin, when I ran into this plugin, and I think with a little stretching this plugin could provide a background for the next scenario:

    We would like our releases to be ready ASAP. But on the other hand we need to generate Maven Site, which take a really long time (svnstat, pmd, findbugs, etc.). So I thought to decouple the release from the site rendering, and to execute site at idle time, - somewhere around 2am. 

     This plugin is now capable of executing mvn site after the release, but I would like to be able to:

    • schedule the build
    • bind the build to a node

    That how site genertaion of sites (in my case) would not interfer our releases.

    What do you think? 

    I'm ready to contribute.

    Regards, Lorand.

    1. I would just create an additional Hudson job that handles the site generation.  See this article on suggestions for breaking up a long running build.

  11. Would it be possible to enable GString parsing in the parameter default value - possibly enabled as a checbox to retain backwards compatibility?

    I would like to set the default value to include the current date as in "Release_2009_09_30" by setting the default string to

    "Release_${new SimpleDateFormat('yyyy-MM-dd').format(new Date())}"

    But the user should still be able to edit this before starting the release.

    1. This sounds like a neat idea.  The release plugin leverages the built in Hudson support for build parameters so you'd need to add support there.  I'd suggest writing your own plugin that contributes a new parameter type.  I did this myself with the Validating String Parameter Plugin.

  12. Hello --

    I updated the Release plugin from v1.7 -> v1.8.  Upon restarting my hudson instance the following errors were encountered:

    WARNING: Failed to load a project
    java.lang.NoClassDefFoundError: hudson/plugins/release/dashboard/RecentReleasesPortlet
            at java.lang.Class.getDeclaringClass(Native Method)

    This prevented all existing jobs from initializing in the hudson display.  Backed it back and all was well again.  Is this a localized problem or something more central to the new version?  Let me know what you think.  This is a useful plugin so I want to continue to use it's features.  Thanks for your work.


    1. Sorry about that.  I failed to test the release plugin with an instance of Hudson that did not have the Dashboard View plugin installed. I'll have to cut another release.

      1. Unknown User (newguy)

        I got that error too. After installing Release plugin 1.8 hudson 1.328 will never start again. There are tons of errors in the log.

        I think this is definitely caused by the relationship between Dashboard View plugin and Release plugin. After I installed Dashboard View plugin everything goes smoothly with Release plugin.

        1. Release 1.9 addresses this issue.

    2. Unknown User (chamaster)

      I needed to manually remore release/, release.hpi in .hudson/plugins folder to have hudson work again.

  13. Unknown User (max khon)

    Could you add support for multiconfiguration projects, please?

    1. Could you open an enhancement request describing the use case that you are interested in?

  14. The release template does not seem to like my parameter, which has a dot in it. After a release, below the build summary the tag reads

    'Release #${project.version}'



    works fine, but


    does not. I tried with release plugin v1.7 and v1.9 and hudson v1.327.

  15. Is it possible that a failed build would not be labeled as a Release build (locked, published in dashboard, etc) but just treated as a normal build failure?How do I configure this?

    If this is currently not supported it would be great to have it in one of the next releases.

    Thanks a lot for this great plugin.

    1. When I looked at this a while back, it was not possible using the BuildWrapper extension point to detect if a build failed or not. 

      1. Just looked again and it looks like since 1.337, BuildWrapper's are able to get the result state of the build.  I'll make this change to treat builds that have failed as regular builds.  I prefer this as well.

      2. As I'm looking at this, I think I should keep the registration that this was supposed to be a release build, but I won't automatically mark the build to keep forever.

  16. Unknown User (

    Would it be possible to add different SCM credentials option much like how you tag a release in Hudson, or like the Maven 2 plugin allows you to do before you build the release?  I would rather use this plugin than be tied to using the Maven2 project type, however because there is no option to input different SCM credentials at build time, it doesn't make it a viable candidate.

  17. Unknown User (

    is there a way that only archive artifact if it is a release build?

    1. Unfortunately not. This needs to be supported by core.
      I already opened a JIRA request for a related issue:

      Hopefully I can work on it sometime soon.

  18. Is there any chance that this plugin can allow the definition of the release goals instead of using the jobs build goals and options? This would allow a single job to be repurposed for regular CI builds and for releases.


    1. This would be an enhancement.  Currently it always runs the regular build steps, running the configured additional release steps before and after the build.  You can open a JIRA if you like.

  19. This plugin is almost exactly what I was looking for, so thanks for starters!

    One feature that would be great is if there was a way to trigger a release build via passing parameters. In our environment, we have a bunch of independent projects which each have their own jobs. When we build a release, we need to build all of those projects as a release build. What I am thinking of is something similar to how a parameterized build works today, but the trigger would be something like:


    which would then schedule the release build with the parameters passed in via the URL and could be triggered with the Parameterized Trigger Plugin

    I have looked at the source, but I have not figured out how to implement that yet. I was wondering if instead of having ReleaseAction implement Action if I could have it extend hudson.model.ParametersAction , but I think it is going to be a lot more complicated than that.

    In the mean time, I have modified the plugin be adding a field where you specify a boolean parameter which gets checked and if set true performs the release, but this does not really feels like the best solution.

  20. Is there a way for downstream Jobs to also be marked as Released (with the Released icon)? For example, if I manually trigger JobA with the release button, I'd like JobB and JobC (both triggered from JobA) to be marked with the Released Icon (eg: they are variants of the same code). 

  21. Is there a possibility of adding multi-config job support in this plugin?


  22. Can support for Job Type 'Ivy project' be added? How hard would that be. I do have some Java programming skill and am not afraid of GitHub. Can anyone give me any pointers?

    1. Please open a JIRA feature request for this, so it doesn't get lost.

      Apart from that, feel free to fork the release-plugin from and open a pull request when you have it working. (smile)

      First thing would be to change hudson.plugins.release.ReleaseWrapper.DescriptorImpl.isApplicable(AbstractProject<?, ?>) to include the IvyModuleSet class.
      This should make it show up for an Ivy project in general. I don't know if any specific Ivy customizations are needed beyond that.

      1. Thanks. A JIRA feature request has been added: JENKINS-11659.

        I did clone the plugin and tried to add the customization you suggested. Rather a lovely system the plugin-build-support that so nicely fires up Jenkins and allow me to stay in Eclipse and play around!

        I made the dependency on Ivy project optional and loaded the class by name to make sure I would not impose Ivy project upon the harmless Jenkins-user ;) Hope I can keep it that way. ;)

        The configuration now does show up in the Ivy project configuration. But now I have two issues:

        1. The release number does not show in the builds-list to the left of my Ivy project
        2. The release-step is not executed.

        I presume I will have to do some jelly work to get 1 going. (The release number is stored in the 'Release' page when I hit 'Release' below the 'Build now' link.) But I'm not to fussy to live without it at the moment. Number 2 is rather mote important:

        For number 2 I'm not sure where to go. The Ivy project is rather a fancy system that will create Jenkins jobs on-the-fly. And I'm not sure if the top-level job (the one you create manually) will allow me to do a step after all other sub-jobs have completed successfully. Are there any pointers?

  23. It is possible to execute the release build from command line. For example:(It works for me)

    Normal build: curl -X POST http://jenkins/job/test/build -d token=zorn --data-urlencode json="{\"parameter\": [{\"name\": \"var1\", \"value\":\"val1\"}], \"\": \"\"}"

    Release Build: curl -X POST http://jenkins/job/test/release/submit -d token=zorn --data-urlencode json="{\"parameter\": [{\"name\": \"var1\", \"value\":\"val1\"}], \"\": \"\"}"

  24. We're running version 2.4.1 with the 1.565.1 core. In the "Promote builds when..." section of the project configuration page, the criterion labeled "If the build is a release build" occurs twice -- as the first AND second options in the "Criteria" list. Is anyone else seeing this?

    P.S. We're running version 2.18 of the Promoted Builds plugin

  25. With Jenkins 2.x the build parameters aren't resolved anymore. Running Jenkins 2.6 with version 2.5.4 (or 2.4.1) following output appears:

         [echo] classes.dir = C:\.jenkins\jobs\brave-build-branch\z_release\brave/classes
         [java] BuildHelper started with parameters: "pre" "..//brave2/src/main/resources" "" "$

    Unknown macro: {releaseVersion}

         [java] Setting Release Version to $

    on file ..//brave2/src/main/resources/

    Total time: 2 seconds
    [brave] $ cmd.exe /C "C:\.jenkins\tools\hudson.tasks.Ant_AntInstallation\Ant1.9.4\bin\ant.bat -file build.xml build && exit %%ERRORLEVEL%%"

    In Jenkins 1.656 and release plugin version 2.4.1 it shows this correct output:

         [echo] classes.dir = C:\.jenkins\jobs\brave-build-branch\z_release\brave/classes
         [java] BuildHelper started with parameters: "pre" "..//brave2/src/main/resources" "" "3.2.3-rc1-12528"
         [java] Setting Release Version to 3.2.3-rc1-12528 on file ..//brave2/src/main/resources/

    Total time: 10 seconds
    [brave] $ cmd.exe /C "C:\.jenkins\tools\hudson.tasks.Ant_AntInstallation\Ant1.9.4\bin\ant.bat -file build.xml -Ddatabase=brave -DreleaseVersion=3.2.3-rc1-12528 build && exit %%ERRORLEVEL%%"

    The String parameters releaseVersion, targetServer and database are defined in the job. After having updated Jenkins to the higher version, the build doesn't produce the correct output. Downgrading Jenkins did help in getting the correct output again.

  26. I'm having a problem adding a release step after successful build in a freestyle project. I am using Jenkins 2.42 and Release plugin 2.6.1.

    When I run my very simple job, I just want to checkpoint the Integrity project using the PTC Integrity plugin after the build, but I get the following console output

    D:\.jenkins\workspace\OnlineTraining_Paul>exit 0
    Build failed!  Skipping Integrity Checkpoint step!
    Finished: SUCCESS

    Where is the Release plugin getting the information that the Build has failed, when it hasn't?

    Thanks in advance.

    1. Does the Release plugin only work with a Maven project? All I can think of is that the plugin is expecting a Build Result from Maven and when it doesn't get it, it thinks the build has failed.

      Anybody got any ideas?

Write a comment…