Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.8.0
    • Fix Version/s: 0.8.0
    • Component/s: packaging
    • Labels:
      None

      Description

      This target has been removed a while ago.

      1. KAFKA-843.patch
        5 kB
        Cosmin Lehene
      2. KAFKA-843.patch
        5 kB
        Cosmin Lehene
      3. 0001-KAFKA-843-Addendum-comply-with-Semantic-Versioning-2.patch
        1 kB
        Cosmin Lehene
      4. 0001-KAFKA-843-Addendum-comply-with-Semantic-Versioning-2.patch
        2 kB
        Cosmin Lehene

        Issue Links

          Activity

          Hide
          Jun Rao added a comment -

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

          Show
          Jun Rao added a comment - Thanks for the latest patch. +1. Committed to 0.8.
          Hide
          Cosmin Lehene added a comment -

          Added new patch that fixes:

          • extra zip in target dir
          • IO.zip hangs if zip file already there
          • proper path filtering for zip target
          Show
          Cosmin Lehene added a comment - Added new patch that fixes: extra zip in target dir IO.zip hangs if zip file already there proper path filtering for zip target
          Hide
          Jun Rao added a comment -

          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?

          Show
          Jun Rao added a comment - 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?
          Hide
          Cosmin Lehene added a comment -

          Jun Rao Is the last patch ok?

          Show
          Cosmin Lehene added a comment - Jun Rao Is the last patch ok?
          Hide
          Cosmin Lehene added a comment - - edited

          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.

          Show
          Cosmin Lehene added a comment - - edited 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.
          Hide
          Jun Rao added a comment -

          Neha,

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

          Show
          Jun Rao added a comment - Neha, ./sbt release-zip seems to work for me on a fresh checkout of 0.8. Could you do ./sbt clean and retry?
          Hide
          Scott Carey added a comment -

          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.

          Show
          Scott Carey added a comment - 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.
          Hide
          Neha Narkhede added a comment -

          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

          {file:/Users/nnarkhed/Projects/kafka-git-idea/project/}

          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

          Show
          Neha Narkhede added a comment - 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 {file:/Users/nnarkhed/Projects/kafka-git-idea/project/} 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
          Hide
          Jun Rao added a comment -

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

          Show
          Jun Rao added a comment - Cosmin, do you want to submit a patch for your suggestion? Perhaps we can default buildNumber to empty.
          Hide
          Cosmin Lehene added a comment -

          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/

          Show
          Cosmin Lehene added a comment - 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/
          Hide
          Cosmin Lehene added a comment - - edited

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

          Show
          Cosmin Lehene added a comment - - edited Perhaps, then, append -buildNumber if build.number non empty and leave it as is if absent?
          Hide
          Scott Carey added a comment -

          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.

          Show
          Scott Carey added a comment - 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.
          Hide
          Cosmin Lehene added a comment -

          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

          Show
          Cosmin Lehene added a comment - 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
          Hide
          Scott Carey added a comment -

          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.

          Show
          Scott Carey added a comment - 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.
          Hide
          Jun Rao added a comment -

          Thanks for the second patch. Committed to 0.8.

          Show
          Jun Rao added a comment - Thanks for the second patch. Committed to 0.8.
          Hide
          Cosmin Lehene added a comment -

          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

          Show
          Cosmin Lehene added a comment - 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
          Hide
          Cosmin Lehene added a comment -

          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

          Show
          Cosmin Lehene added a comment - 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
          Hide
          Jun Rao added a comment -

          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

          Show
          Jun Rao added a comment - 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
          Hide
          Cosmin Lehene added a comment - - edited

          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.

          Show
          Cosmin Lehene added a comment - - edited 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.

            People

            • Assignee:
              Cosmin Lehene
              Reporter:
              Cosmin Lehene
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2h
                2h
                Remaining:
                Remaining Estimate - 2h
                2h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development