added release, release-zip, release-tar tasks along with the possibility to take the build number (defaults to SNAPSHOT) from BUILD_NUMBER environment variable (common with jenkins and other build servers)

There are several plugins that are related (sbt/sbt-release, sbt/sbt-native-packager, guardian/sbt-dist-plugin, guardian/sbt-version-info-plugin, twitter/sbt-package-dist). I initially tried sbt-package-dist, but it has to be rebuilt in order to work with sbt 0.12 and it seems to be more or less dead.

This was my first encounter with sbt so it might not be as idiomatic as it should be.

Cosmin, thanks for the patch. This is very helpful. The patch seems to work. A couple of comments:

1. The new targets don't seem to be show up in the output of ./sbt tasks

2. The zip release file is put in a different directory from the tar release file.
./target/RELEASE/kafka_2.8.0-0.8-SNAPSHOT.tar.gz
./target/kafka_2.8.0-0.8-SNAPSHOT.zip

Changed the patch so that both zip and tar are created in the target/RELEASE dir.

I wasn't able to make the taks show up with ./sbt tasks

Jun,

I posted the question to the sbt mailing lists about the tasks. It may be an sbt issue. Can we go ahead with it?

Thanks,
Cosmin

Thanks for the second patch. Committed to 0.8.

This seems to require that there be a "buildNumber", and that it cannot be empty.

It constructs a version using this, for example "0.8-" + buildNumber. A final release will simplly be "0.8" and not "0.8-RELEAE" or with some other postfix.

What is the utility of this build number? The version is "0.8-SNAPSHOT", until it changes for a release or beta, etc.

Scott Carey fi an empty build number is passed it will set it to SNAPSHOT.
The build number is used by various CI servers (e.g. Jenkins) by setting the BUILD_NUMBER environment variable.
This is passed through the sbt script (-Dbuild.number=$BUILD_NUMBER)

Here's an example of a plugin that does something similar https://github.com/guardian/sbt-version-info-plugin

The final release artifact version will be version = "0.8", which cannot be constructed as "0.8-" + buildNumber.

I am not against having the ability to set some sort of custom version for a build if others want it, but I am against such a thing forcing the final release artifact to have a version number that does not conform to the maven version numbering standards.

As an aside, I don't see why one would want to modify the version number based on the build number – maven repositories have a special case for SNAPSHOT (perhaps Ivy is deficient in SNAPSHOT support?). Maven 'snapshot' repositories can have multiple snapshots from different timestamps, and every continuous build system I've used was happy using plain SNAPSHOT and could tell you which SNAPSHOT came from a specific build.

Perhaps, then, append -buildNumber if build.number non empty and leave it as is if absent?

We have a Puppet based deployment so we'll end up deploying multiple snapshots on the testing environments, we use build number to track those.
Here are some ideas on both why you'd want additional information with the version as well as how you may do it right http://semver.org/

Cosmin, do you want to submit a patch for your suggestion? Perhaps we can default buildNumber to empty.

I get the following error when I try the release-zip target

nnarkhed-mn:kafka-git-idea nnarkhed$ ./sbt release-zip
[warn] Detected both new and deprecated style of plugin configuration.
[warn] Ignoring deprecated project/plugins/ directory (/Users/nnarkhed/Projects/kafka-git-idea/project/plugins).
[info] Loading project definition from /Users/nnarkhed/Projects/kafka-git-idea/project
[info] Updating

default-034d47...
[info] Resolving org.scala-sbt#precompiled-2_10_0-m7;0.12.1 ...
[info] Done updating.
[info] Compiling 1 Scala source to /Users/nnarkhed/Projects/kafka-git-idea/project/target/scala-2.9.2/sbt-0.12/classes...
/Users/nnarkhed/Projects/kafka-git-idea/build.sbt:22: error: not found: value commonDeps
commonDeps :+ (sv match {
^
[error] Type error in expression
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? r

Another suggestion:

What if buildNumber was only appended to the version?

So the current version on the branch is 0.8-SNAPSHOT, and adding a build number "12345" gives:

"0.8-SNAPSHOT-12345"

And if the version was "0.8.beta1" adding a build number would be:

"0.8.beta1-12345"

My reasoning is that it is nice to consolidate the "true current version" into one value and have that be set in one place and not constructed. This includes when there is a SNAPSHOT and when there is not. This is so that a release process would involve changing that one value, committing, and tagging – what is committed and tagged as a release will have the version set in source, not ephemeral in the environment that built it.

Neha,

./sbt release-zip seems to work for me on a fresh checkout of 0.8. Could you do ./sbt clean and retry?

Attached an addendum (applies over 0.8 with previous patch)
that includes the discussed changes. It complies to Semantic Versioning 2.0.0-rc.1 (http://semver.org/)

Changes:

• version includes major minor and patch and pre-release version, hence it's 0.8.0-SNAPSHOT
• build number is optional and is appended with a plus sign, hence if build number is 199 the full version will be 0.8.0-SNAPSHOT+199

I suggest sticking to semantic versioning. It's not anything new, it's just very clear and easy to explain and rely on.

Also, handling versioning should probably be done using a release plugin like sbt-release (https://github.com/sbt/sbt-release) so we avoid cluttering the Build.scala file.

Jun Rao Is the last patch ok?

Thanks for the addendum. It looks fine. I found another minor issue (exists without the new patch). When doing a zip release, I saw the zip file in two places:
./target/kafka_2.8.0-0.8-SNAPSHOT.zip
./target/RELEASE/kafka_2.8.0-0.8-SNAPSHOT.zip

The tar release only exists in the RELEASE directory.

Could you fix that an provide a new patch?

Added new patch that fixes:

• extra zip in target dir
• IO.zip hangs if zip file already there
• proper path filtering for zip target

Thanks for the latest patch. +1. Committed to 0.8.