sbt / sbt-release Goto Github PK

Is it possible run a release on an aggregated project?

The latest sbt-release (v0.5-SNAPSHOT) doesn't seem to support non-interactive mode (using with-defaults). Please enable this state as part of the "with-defaults" release process for non-interactive mode.

Thanks!

Hi, it's undocumented how to release with signed artifacts using the sbt-pgp-plugin. Do I need to set up a custom release process just for this? Publishing signed artifacts is required for releases to OSS Sonatype.

I'm using SBT 0.12.3 and sbt-extras

I've added the following to my build.sbt file as outlined in the wiki documentation.

// required for release plugin
releaseSettings

// bump the bugfix version and append '-SNAPSHOT', eg. 1.2.1 -> 1.2.2-SNAPSHOT
nextVersion := { ver => Version(ver).map{_.bumpBugfix.asSnapshot.string}.getOrElse(versionFormatError) }

I then get the following errors.
(Paths have been removed)

$ sbt
Detected sbt version 0.12.3
Starting sbt: invoke with -help for other options
[info] Loading project definition from /.../project
/.../build.sbt:10: error: not found: value nextVersion
nextVersion := { ver => Version(ver).map{nextVersion;_.bumpBugfix.asSnapshot.string}.getOrElse(versionFormatError) }
^
/.../build.sbt:10: error: reassignment to val
nextVersion := { ver => Version(ver).map{nextVersion; _.bumpBugfix.asSnapshot.string}.getOrElse(versionFormatError) }

Thank you,

I'd like to be able to customize the git tag.

For example, I'd like to write SPECS2-1.2.3 instead of v1.2.3 to keep my history consistent.

Thereby we can get it into the standard plugins repos.

oss.sonatype.org syncs with maven central.

versionFormatError presents [0-9]+([0-9]+)?([0-9]+)?(-.*)? as the validity pattern for version strings. This pattern simplifies to [0-9]+(-.*)? which doesn't well describe a valid version string.

Why not use the one actually applied to split a version string into major,minor,patch,qualifier parts here?

I might be wrong, but I think in the latest release, if the test step fails, the release isn't terminated. I think this was previously the case.

Hi,

how can i access the version from version.sbt file programmatically from within Build.scala. I'm trying to use sbt-release with a play2 project where the version has to be passed to the project itself like:

val appVersion = ""
val main = play.Project(appName, appVersion, appDependencies, settings = Defaults.defaultSettings ++ releaseSettings).settings( 

Sorry for asking here but i found no other appropriate place.

Thanks

Marcus

I'm having trouble getting the release plugin (release 0.4, and my project is currently using sbt 0.11.1) to publish artifacts using the version I'm supplying as releaseVersion to inquireVersions.

Initially, my project has e.g. version := "0.1-SNAPSHOT".

I run "sbt release", using the default releaseProcess. In the inquireVersions ReleasePart, it suggests "0.1" as the releaseVersion, and I accept the suggestion.

When I reach the releaseTask(publish in Global in ref) ReleasePart, sbt packages and publishes a "0.1-SNAPSHOT" version of my artifact -- rather than the "0.1" artifacts I were expecting.

To check whether there's something strange in my project's sbt config that's causing these problems, I've also tried to add the release plugin to a checkout of the "sbt-release" project, and supplied a non-default releaseVersion there. However, that also did not work as I expected it to:

[info] Loading project definition from /Users/hmeland/src/sbt-release/project
[info] Set current project to sbt-release (in build file:/Users/hmeland/src/sbt-release/)
> about
[info] This is sbt 0.11.2
[info] The current project is {file:/Users/hmeland/src/sbt-release/}default-b74fd5
[info] The current project is built against Scala 2.9.1
[info] sbt, sbt plugins, and build definitions are using Scala 2.9.1
> release
[info] Starting release process off git commit: 114873ede58616d2a44a84330390955dc7e10465
[info] Updating {file:/Users/hmeland/src/sbt-release/}default-b74fd5...
[info] Resolving org.scala-tools.sbt#sbt_2.9.1;0.11.2 ...
[...]
[info] Done updating.
[info] Compiling 5 Scala sources to /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/classes...
Release version [0.4] : 0.5
Next version [0.6-SNAPSHOT] : 
[info] No tests to run for test:test
[success] Total time: 0 s, completed Jan 3, 2012 6:00:08 PM
[info] Setting version to '0.5'.
[info] Reapplying settings...
[info] Set current project to sbt-release (in build file:/Users/hmeland/src/sbt-release/)
[info] Reapplying settings...
[info] Set current project to sbt-release (in build file:/Users/hmeland/src/sbt-release/)
[info] Reapplying settings...
[info] Set current project to sbt-release (in build file:/Users/hmeland/src/sbt-release/)
[info] Packaging /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/sbt-release-0.4-sources.jar ...
[info] Generating API documentation for main sources...
[info] Packaging /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/sbt-release-0.4.jar ...
[info] Wrote /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/sbt-release-0.4.pom
[info] Done packaging.
[info] :: delivering :: com.github.gseitz#sbt-release;0.4 :: 0.4 :: release :: Tue Jan 03 18:00:09 CET 2012
[info]  delivering ivy file to /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/ivy-0.4.xml
[info] Done packaging.
model contains 11 documentable templates
[info] API documentation generation successful.
[info] Packaging /Users/hmeland/src/sbt-release/target/scala-2.9.1/sbt-0.11.2/sbt-release-0.4-javadoc.jar ...
[info] Done packaging.
[info]  published sbt-release to /Users/hmeland/dev/repo/com/github/gseitz/sbt-release_2.9.1_0.11.2/0.4/sbt-release-0.4.pom
[info]  published sbt-release to /Users/hmeland/dev/repo/com/github/gseitz/sbt-release_2.9.1_0.11.2/0.4/sbt-release-0.4.jar
[info]  published sbt-release to /Users/hmeland/dev/repo/com/github/gseitz/sbt-release_2.9.1_0.11.2/0.4/sbt-release-0.4-sources.jar
[info]  published sbt-release to /Users/hmeland/dev/repo/com/github/gseitz/sbt-release_2.9.1_0.11.2/0.4/sbt-release-0.4-javadoc.jar
[success] Total time: 3 s, completed Jan 3, 2012 6:00:11 PM

Is this a bug (in the plugin or in sbt itself?), or is it just me that's going about this the wrong way, somehow?

Allow the user to commit from the SBT shell:

> release with-defaults
[info] Working directory is dirty:
[info] 
[info]  ?? project-a/

Enter a message to add everything and commit: bla bla bla

Push changes to the remote repository (y/n)? [y] > y
[error] To git@git:efgfp/analytics.git
[error]    ec38e8a..24aa91c  master -> master
[error] To git@git:efgfp/analytics.git
[error]  * [new tag]         v0.7.17 -> v0.7.17
[info] Set current project to analytics-tools (in build file:/C:/code/analytics/)

I'd suggest to add a line here with "git push sends it's console output to standard error, which will cause the next few lines to be marked as [error].

For as much as I would like to use Git, that's not currently possible in my organization. Can we please have Subversion support like Maven has?

Thanks.

Instead of bumping up from 0.5.0-SNAPSHOT to 0.5.1-SNAPSHOT it should be 0.6.0-SNAPSHOT.

sbt-release 0.8 allows versions like 1.2.3-M4 but does not allow 1.2.3.M4. The latter form is common for OSGi bundles that use the milestone (Mx), release candidate (RCx), and release (RELEASE) qualifier as the fourth component of a version string.

This can be supported by allowing a period in the VersionR pattern:

val VersionR = """([0-9]+)(?:(?:\.([0-9]+))?(?:\.([0-9]+))?)?([\-.0-9a-zA-Z]*)?""".r

Rather than submitting this as a PR, I'm opening a ticket based on our Twitter conversation -- I'm not sure if there are other version strings you want to add support for that aren't supported by the current regex.

sbt-release ignores scalaVersion and uses Scala 2.10.3 by default if crossScalaVersions is not set. I worked around this by setting

crossScalaVersions := Seq(scalaVersion.value)

The README.md implies that it should use scalaVersion by default in "Cross building during a release." Even before I read that, I expected it to use scalaVersion.

git clone https://github.com/dwalend/ScalaGraphMinimizer.git and comment out the crossScalaVersions line (after I push) in build.sbt if you want to mess around with some example code.

Thanks,

Dave

For those of us who checkout Unix line endings on Windows.

Another possibility: don't include any line separators at all.

/cc @gbasler

The git command doesn't seem to work on windows (dos or cygwin):

java.io.IOException: Cannot run program "git": CreateProcess error=2, The system cannot find the file specified

I suspect that it might be a path issue so it'd be good if you could open the git command definition (which is private now).

When cutting a release on a branch created from a tag (e.g. for a hot-fix release of an older version), it shouldn't be necessary to have a remote tracking branch set up.

The created tag will point to the commit anyway, so a remote tracking branch shouldn't be mandatory.

When using git as vcs, "working copy is dirty" error is thrown when the user has untracked files, but no uncommitted changes

I'll get to this before too long and happy to send a pull request. If someone else wants to get to it first, all the better. :)

Basically I want a project to be able to configure that running "release" automatically does "release cross". Otherwise it's too error prone -- we have a bunch of projects, some are "release cross" and some are just "release".

I'd love if we could settle on the right configuration name in advance?

releaseCrossByDefault := true

or something like that?

It would be nice to have an option to be able to increment and release sub projects independently in a multi project build.

There are files in a project that contain a reference to the version (like the README). It would be nice if we had a release step that could add it.

Below an example of how I hacked it in.

val updateReadmeVersion = { s:State =>
  val contents = IO.read(file("README.md"))
  //
  val p = Project.extract(s)
  //"org.qirx" %% "sbt-webjar-resources" % "version"
  val pattern = "(\"" + p.get(organization) + "\"\\s+%+\\s+\"" + p.get(name) + "\"\\s+%\\s+\")[\\w\\.]+(\")"
  val newContents = contents.replaceAll(pattern, "$1" + p.get(releaseVersion)(p.get(version)) + "$2")
  IO.write(file("README.md"), newContents)
  //
  val vcs = p.get(versionControlSystem).getOrElse(sys.error("Aborting release. Working directory is not a repository of a recognized VCS."))
  vcs.add(file("README.md").getAbsolutePath) !! s.log
  //
  s
}

releaseProcess := {
  val originalReleaseSteps = releaseProcess.value
  val (beforeCommitReleaseVersion, rest) =
    originalReleaseSteps.span(_ != commitReleaseVersion)
  //
  (beforeCommitReleaseVersion :+ (updateReadmeVersion:ReleaseStep)) ++
  rest.filter(_ != pushChanges)
}

Btw, awesome plugin! Thanks for providing it.

Is there a complete working example of using sbt-release with a custom release process somewhere?

I have tried to get the pieces from the README.md to work in my Build.scala file with no success. Most probably due to my inexperience with sbt...

What I want to do is call the one-jar task from sbt-onejar instead of publish when doing a release.

Are you planning to compile this plugin to scala 2.11?

It would be nice to have sbt-release write the git commit sha and tag of the release version that will be built, into the manifest file, as well as the release version that is decided upon by sbt-release (META-INF/MANIFEST.MF)

Some notes:
You can use git describe to get the current tag, and git rev-parse HEAD to get the commit tag at HEAD.

(Be sure to use 'git tag -a', so 'git describe' gives you the correct answer)

Version.sbt file is written to a hard-coded location. This isn't always convenient; could it be a setting instead, with the current location as the default?

"release cross" works great for me, but if I include "skip-tests", it only releases the default scala version.

Appending of "in ThisBuild" to the version.sbt forces SBT to apply the same version across all subprojects, even if they are unrelated. We use the plugin for maintaining separate versions for each of the subprojects, and so would like to have a flag that disables this. Currently, after running 'release' we need to manually modify the version.sbt file to remove "in ThisBuild". So it would be great if that was configurable.

If version.sbt is not scoped to ThisBuild, e.g: version := "0.1-SNAPSHOT". The release process will fail at applying the new version: version scoped to the current project will override version scoped to ThisBuild.

As I explained in this case here - sbt/sbt#1209 - it would be rather necessary to see what build tasks is the release command executing under the hood. If they are wrapped into ReleaseSteps, execution of them cannot be observed simply via sbt --debug any longer. Thus, the release command is hard to debug, as it is not clearly visible which of my tasks and in what order are actually executing.

hi,

it's possible to do release process for project with submodules which have their own version?

for example:

root - ver 0.1

• api - ver 0.3
• common - ver 0.2
• core - ver 0.4
• integration - ver 0.2

root aggregate api, common, core and integration

when in root'll do command 'release' i want to bump version for each submodules:

• root 0.2
  • api 0.4
  • common -0.3
  • core 0.5
  • integration 0.3

how to configure release process? and big question is what about git tags.

I filed an issue to main SBT project that should probably have been filed to sbt-release. To summarize, the issue is that Project.extract(st).runAggregated(key, st) does not seem to actually execute the task, making the releaseTask shortcut invalid... any ideas? Is it a bug?

Full issue description including some snippets is here under the main SBT project : sbt/sbt#1210

Why do you run tests before and after setting the release version?

If the test suite is large this adds to the release time, without much added value (that I can see).

Hello. The listed repository (http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases) is 404ed, where other artifactoryonline repos seem to be online. Is this still the right place to get sbt-release artifacts?

On my project I normally use "sbt +publish" it appears I can't do the same with the release command, I'm not sure if this means I need to tweak the release steps to handle this correctly.

When I run the release task, it gets to the point of setting the next version, which succeeds, then it logs at error level what seems to be git-fetch output (updated branches / tags).

In order to make the user experience even better, I suggest the following refactorings according to the sbt plugins best practices:

• Rename Release to ReleasePlugin (low priority) and extend Plugin (high priority); then we don't have to import sbtrelease._ or use fully qualified names
• Put ReleaseKeys under ReleasePlugin, then again we don't need imports or fqns

Thanks for considering

Hi, I need to use sbt 0.13 because it fixes a very important incremental recompilation issue (and also to work on the new test framework). So that would be very nice if you could publish a version for it. Thanks.

Not an issue. Just to confirm.

Each of the source file (i.e Vcs.scala) contains next package declaration:

package sbt release;

On the other hand files are located under next directory src/main/scala as a result some IDE's does not handle properly such situation and it is harder to create some custom solution based on sbt-release plugin.
Could be possible to place those files under src/main/scala/sbtrelease direcotory in order to reflect package declaration?

Releasing with sbt 0.13.0 doesn't sign the artifacts. However, if you run sbt publishSigned from the command line the artifacts are signed correctly.

In https://github.com/sbt/sbt-release/blob/v0.8.1/src/main/scala/ReleaseExtra.scala#L149

When using with-defaults, if this particular error condition is triggered due to a tag already existing in the repository, the output message is not clear that that is the cause. This makes it difficult to quickly diagnose and fix the problem, when looking solely at log output.

It would be sufficient to amend the line to read similarly to the interactive output, like: "Tag [%s] exists. Aborting release!"

I just released from a non-master branch and am trying to determine if the plugin or Jenkins was responsible for merging to master as part of it. Is that expected or perhaps it was a nuance with my Jenkins job?

Make sure aggregated projects are all using the current project version to avoid publishing incorrect versions.

To make it easier to use the automatically detected VCS, the cmd method (currently protected in GitLike) should be made public and moved to the Vcs trait.

I'm getting this exception during release:

I'm running scala 2.9.1 with sbt 0.11.2:

[debug] Other repositories:
[debug]     xxx http:/xxx
[debug] Default repositories:
[debug]     Raw(ProjectResolver(inter-project, mapped: ))
[debug]     FileRepository(local,FileConfiguration(true,None),sbt.Patterns@3c8d785e)
[debug]     scct repository: http://mtkopone.github.com/scct/maven-repo
[debug]     snapshots: http://scala-tools.org/repo-snapshots
[debug]     releases: http://scala-tools.org/repo-releases
[debug]     releases: https://oss.sonatype.org/content/repositories/releases/
[debug]     snapshots: https://oss.sonatype.org/content/repositories/snapshots/
[debug]     releases: http://guice-maven.googlecode.com/svn/trunk
[debug]     releases: http://akka.io/repository
[debug]     snapshots: http://repository.apache.org/snapshots/
[debug]     SourceforgeReleases: https://oss.sonatype.org/content/repositories/sourceforge-releases/
[debug]     SourceforgeSnapshots: https://oss.sonatype.org/content/repositories/sourceforge-snapshots/
[debug]     Terracotta Snapshots: http://snapshots.terracotta.org/
[debug]     public: http://repo1.maven.org/maven2/
[debug]     Scala-Tools Maven2 Repository: http://scala-tools.org/repo-releases
[debug] Using inline dependencies specified in Scala.
[debug] post 1.3 ivy file: using exact as default matcher
[debug] Running task... Cancelable: true, max worker threads: 4, check cycles: false
java.lang.RuntimeException: Nonzero exit value: 1
    at scala.sys.package$.error(package.scala:27)
    at scala.Predef$.error(Predef.scala:66)
    at sbt.AbstractProcessBuilder.getString(ProcessImpl.scala:140)
    at sbt.AbstractProcessBuilder.$bang$bang(ProcessImpl.scala:143)
    at sbtrelease.ReleaseStateTransformations$$anonfun$sbtrelease$ReleaseStateTransformations$$commitVersion$1.apply(ReleaseExtra.scala:105)
    at sbtrelease.ReleaseStateTransformations$$anonfun$sbtrelease$ReleaseStateTransformations$$commitVersion$1.apply(ReleaseExtra.scala:101)
    at sbtrelease.ReleaseStateTransformations$$anonfun$commitReleaseVersion$1.apply(ReleaseExtra.scala:93)
    at sbtrelease.ReleaseStateTransformations$$anonfun$commitReleaseVersion$1.apply(ReleaseExtra.scala:92)
    at scala.Function$$anonfun$chain$1$$anonfun$apply$1.apply(Function.scala:26)
    at scala.Function$$anonfun$chain$1$$anonfun$apply$1.apply(Function.scala:26)
    at scala.collection.LinearSeqOptimized$class.foldLeft(LinearSeqOptimized.scala:111)
    at scala.collection.immutable.List.foldLeft(List.scala:45)
    at scala.collection.TraversableOnce$class.$div$colon(TraversableOnce.scala:137)
    at scala.collection.immutable.List.$div$colon(List.scala:45)
    at scala.Function$$anonfun$chain$1.apply(Function.scala:26)
    at sbtrelease.ReleaseKeys$$anonfun$2.apply(ReleasePlugin.scala:31)
    at sbtrelease.ReleaseKeys$$anonfun$2.apply(ReleasePlugin.scala:23)
    at sbt.Command$$anonfun$applyEffect$1$$anonfun$apply$2.apply(Command.scala:62)
    at sbt.Command$$anonfun$applyEffect$1$$anonfun$apply$2.apply(Command.scala:62)
    at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:64)
    at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:64)
    at sbt.Command$.process(Command.scala:92)
    at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(Main.scala:121)
    at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(Main.scala:121)
    at sbt.State$$anon$1.process(State.scala:154)
    at sbt.MainLoop$$anonfun$next$1.apply(Main.scala:121)
    at sbt.MainLoop$$anonfun$next$1.apply(Main.scala:121)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
    at sbt.MainLoop$.next(Main.scala:121)
    at sbt.MainLoop$.run(Main.scala:114)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(Main.scala:103)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(Main.scala:100)
    at sbt.Using.apply(Using.scala:25)
    at sbt.MainLoop$.runWithNewLog(Main.scala:100)
    at sbt.MainLoop$.runAndClearLast(Main.scala:83)
    at sbt.MainLoop$.runLoggedLoop(Main.scala:67)
    at sbt.MainLoop$.runLogged(Main.scala:60)
    at sbt.xMain.run(Main.scala:33)
    at xsbt.boot.Launch$.run(Launch.scala:54)
    at xsbt.boot.Launch$$anonfun$explicit$1.apply(Launch.scala:43)
    at xsbt.boot.Launch$.launch(Launch.scala:68)
    at xsbt.boot.Launch$.apply(Launch.scala:14)
    at xsbt.boot.Boot$.runImpl(Boot.scala:25)
    at xsbt.boot.Boot$.main(Boot.scala:15)
    at xsbt.boot.Boot.main(Boot.scala)

I have a branch, release/0.1.1, from which I'm trying to run release with-defaults.

I run the following before doing so, so that it doesn't complain about a remote tracking branch: git branch --set-upstream release/0.1.1 origin/release/0.1.1

I receive the following error output and trace:

[info] Starting release process off commit: [removed by me]
[info] Checking remote [.] ...
[error] From .
[error]  * remote-tracking branch origin/release/0.1.1 -> FETCH_HEAD
java.lang.RuntimeException: Nonzero exit value: 128
    at scala.sys.package$.error(package.scala:27)
    at scala.Predef$.error(Predef.scala:142)
    at sbt.AbstractProcessBuilder.getString(ProcessImpl.scala:146)
    at sbt.AbstractProcessBuilder.$bang$bang(ProcessImpl.scala:149)
    at sbtrelease.Git$.isBehindRemote(Vcs.scala:104)
    at sbtrelease.ReleaseStateTransformations$$anonfun$checkUpstream$1.apply(ReleaseExtra.scala:195)
    at sbtrelease.ReleaseStateTransformations$$anonfun$checkUpstream$1.apply(ReleaseExtra.scala:181)
    at sbtrelease.ReleasePlugin$ReleaseKeys$$anonfun$2$$anonfun$apply$1.apply(ReleasePlugin.scala:49)
    at sbtrelease.ReleasePlugin$ReleaseKeys$$anonfun$2$$anonfun$apply$1.apply(ReleasePlugin.scala:49)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at sbtrelease.ReleasePlugin$ReleaseKeys$$anonfun$2.apply(ReleasePlugin.scala:49)
    at sbtrelease.ReleasePlugin$ReleaseKeys$$anonfun$2.apply(ReleasePlugin.scala:33)
    at sbt.Command$$anonfun$applyEffect$1$$anonfun$apply$2.apply(Command.scala:60)
    at sbt.Command$$anonfun$applyEffect$1$$anonfun$apply$2.apply(Command.scala:60)
    at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:62)
    at sbt.Command$$anonfun$applyEffect$2$$anonfun$apply$3.apply(Command.scala:62)
    at sbt.Command$.process(Command.scala:95)
    at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:100)
    at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:100)
    at sbt.State$$anon$1.process(State.scala:179)
    at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:100)
    at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:100)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
    at sbt.MainLoop$.next(MainLoop.scala:100)
    at sbt.MainLoop$.run(MainLoop.scala:93)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:71)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:66)
    at sbt.Using.apply(Using.scala:25)
    at sbt.MainLoop$.runWithNewLog(MainLoop.scala:66)
    at sbt.MainLoop$.runAndClearLast(MainLoop.scala:49)
    at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:33)
    at sbt.MainLoop$.runLogged(MainLoop.scala:25)
    at sbt.StandardMain$.runManaged(Main.scala:57)
    at sbt.xMain.run(Main.scala:29)
    at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:57)
    at xsbt.boot.Launch$.withContextLoader(Launch.scala:77)
    at xsbt.boot.Launch$.run(Launch.scala:57)
    at xsbt.boot.Launch$$anonfun$explicit$1.apply(Launch.scala:45)
    at xsbt.boot.Launch$.launch(Launch.scala:65)
    at xsbt.boot.Launch$.apply(Launch.scala:16)
    at xsbt.boot.Boot$.runImpl(Boot.scala:32)
    at xsbt.boot.Boot$.main(Boot.scala:21)
    at xsbt.boot.Boot.main(Boot.scala)
[error] Nonzero exit value: 128
[error] Use 'last' for the full log.

By contrast and with nearly the same configuration (changing the git branch line as needed, etc.), if I try to release with-defaults from a branch like master without slashes, execution proceeds normally.

About my env: I am running with Jenkins 1.549, sbt 0.13.1 (and so sbt-release 0.8), git 1.7.9.5, for a scala 2.10 project, inside an Ubuntu 12.04 instance.