Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 14 14:26

    dwijnand on master

    Update sbt to 1.3.3 Update sbt to 1.3.3 (#130) Upd… (compare)

  • Oct 14 14:26
    dwijnand closed #130
  • Oct 14 14:17
    scala-steward opened #130
  • Oct 13 07:25

    2m on master

    Update org.eclipse.jgit to 5.5.… Merge pull request #129 from sc… (compare)

  • Oct 13 07:25
    2m closed #129
  • Oct 13 06:34
    scala-steward opened #129
  • Sep 26 07:07

    dwijnand on master

    Update scalacheck to 1.14.2 Update scalacheck to 1.14.2 (#1… (compare)

  • Sep 26 07:07
    dwijnand closed #128
  • Sep 26 06:58
    scala-steward opened #128
  • Sep 22 13:51

    dwijnand on master

    Update sbt to 1.3.2 Update sbt to 1.3.2 (#127) Upd… (compare)

  • Sep 22 13:51
    dwijnand closed #127
  • Sep 22 13:41
    dwijnand synchronize #127
  • Sep 22 09:26

    dwijnand on master

    Update sbt-mima-plugin to 0.6.1 Update sbt-mima-plugin to 0.6.1… (compare)

  • Sep 22 09:26
    dwijnand closed #126
  • Sep 20 21:39
    scala-steward opened #127
  • Sep 20 21:39
    scala-steward opened #126
  • Sep 18 17:06

    dwijnand on master

    Update scalacheck to 1.14.1 Merge pull request #125 from sc… (compare)

  • Sep 18 17:06
    dwijnand closed #125
  • Sep 18 17:00
    scala-steward opened #125
  • Sep 16 13:58

    dwijnand on master

    Update org.eclipse.jgit to 5.5.… Merge pull request #124 from sc… (compare)

Dale Wijnand
@dwijnand
wdym by sbt-crossbuild?
is that a plugin?
Eric K Richardson
@ekrich
yeah, the Scala-js and scala-native studs org.portable-scala
Dale Wijnand
@dwijnand
oh right sbt-crossproject
yeah..
Eric K Richardson
@ekrich
Yeah, that is it - tired now - it is late for me
time for food
Dale Wijnand
@dwijnand
best of luck
there's a different take on that in https://github.com/sjrd/sbt-dynscalajs
I'm off too. Best of luck!
Eric K Richardson
@ekrich
@dwijnand You around and have a couple of minutes?
Dale Wijnand
@dwijnand
I am now... lol
Eric K Richardson
@ekrich
No worries, I sort of hacked through to do what I wanted. You seem to have used some pretty advanced coding in the plugin - I little hard to figure out.
Dale Wijnand
@dwijnand
I'd be happy to explain or, even better, simplify the code.
Eric K Richardson
@ekrich
So, let me tell you what I found. First, adding hash and such is great for stable snapshots for others to use but not so great for a publishLocal work flow working against the latest code.
Eric K Richardson
@ekrich
In Scala Native, Denys starts the next version e.g. 0.4.0-SNAPSHOT into the build via the plugin via the NIR gen code.
Also, if you are build someones lib it is nice to just add snapshot or up the version with a -SNAPSHOT to build it locally and try it out.
The sbt-dynver plugin either has no version ahead of it or the previous tag version - not the next version you may be working on. This is basically the hack I used. https://github.com/ekrich/sconfig/blob/master/build.sbt#L16-L38
Dale Wijnand
@dwijnand
Yeah, dynver is about the changes that have happened after a said release.
If you're working towards 0.4.0, then just tag v0.4.0-M0 or something
but, also, dynver is purposely anti-snapshot, for repeatable builds
so for things like across builds I would just add the project from the other build
ie. ProjectRef
Eric K Richardson
@ekrich
Yeah, but I was talking about really just projects that use other ones. The one I did was utest to get a version that supported the new version of Scala Native, before it is released and utest supports.
That is a good idea though to tag something.
Nick Childers
@Voltir
Did something happen to dynverSeparator ?
Dale Wijnand
@dwijnand
how do you mean?
It's merged but not released.
Nick Childers
@Voltir
As far as I can tell, in 3.3.0, its not a setting key anymore
package sbtdynver
object DynVerPlugin extends sbt.AutoPlugin {
  override def requires : sbt.plugins.JvmPlugin.type = { /* compiled code */ }
  override def trigger : sbt.PluginTrigger = { /* compiled code */ }
  object autoImport extends scala.AnyRef {
    val dynver : sbt.TaskKey[_root_.scala.Predef.String] = { /* compiled code */ }
    val dynverInstance : sbt.SettingKey[sbtdynver.DynVer] = { /* compiled code */ }
    val dynverCurrentDate : sbt.SettingKey[java.util.Date] = { /* compiled code */ }
    val dynverGitDescribeOutput : sbt.SettingKey[scala.Option[sbtdynver.GitDescribeOutput]] = { /* compiled code */ }
    val dynverSonatypeSnapshots : sbt.SettingKey[scala.Boolean] = { /* compiled code */ }
    val dynverGitPreviousStableVersion : sbt.SettingKey[scala.Option[sbtdynver.GitDescribeOutput]] = { /* compiled code */ }
    val dynverCheckVersion : sbt.TaskKey[scala.Boolean] = { /* compiled code */ }
    val dynverAssertVersion : sbt.TaskKey[scala.Unit] = { /* compiled code */ }
    val dynverAssertTagVersion : sbt.TaskKey[scala.Unit] = { /* compiled code */ }
    val isVersionStable : sbt.SettingKey[scala.Boolean] = { /* compiled code */ }
    val previousStableVersion : sbt.SettingKey[scala.Option[_root_.scala.Predef.String]] = { /* compiled code */ }
  }
  override def buildSettings : scala.collection.Seq[sbt.Def.Setting[_1]] = { /* compiled code */ }
}
Dale Wijnand
@dwijnand
it's in master but unreleased
you can depend on 3.3.0+7-d5e88cd5 for now
Nick Childers
@Voltir
ah, ok
thanks :)
Dale Wijnand
@dwijnand
np
Nick Childers
@Voltir
Dynver and coursier dont seem to get along - trying to publishLocal a non-release lib, and I get the following:
Ignoring unparsed versions: Vector(9.0.0+3-665436db)
Ignoring unparsed versions: Vector(9.0.0+3-665436db)
then coursier complains it cant find the lib
Nick Childers
@Voltir

Adding:

version in ThisBuild ~= (_.replace('+', '-'))
dynver in ThisBuild ~= (_.replace('+', '-'))

Fixed my local publish problem

Dale Wijnand
@dwijnand
I think something else might be up because I've definitely resolved artifacts like that with coursier before...
Christof Nolle
@nolledge
Hi, I really like the plugin and the absence of snapshot versions. I was just wondering if you use any strategies to avoid tagging manually? I was thinking about Jenkins to do the tagging according to keywords in the commit message (patch, minor, major).. but I do not like that approach too much because it somewhat pollutes my commit messages with these keywords. Does anyone have another approach or actually does something alike?
Jacob Wang
@jatcwang

Hey @nolledge I'm trying to solve the same problem. I think https://github.com/sbt/sbt-autoversion is part of the way there but the previous version detection is currently broken.

@dwijnand You think it's a good idea to make setting the version optional (default true) for sbt-dynver? I want to reuse the previous version detection but I want to provide my own bumper like in sbt-autoversion

Dale Wijnand
@dwijnand
I don't understand the question.
I'm thinking for that use case: decide what input you want to use (instead of polluting commit messages), then use that input to decide on the next version, then tag the repo, now sbt-dynver will define version from that.
Jacob Wang
@jatcwang

I'm working on a release process for my company's internal libraries:

What I want for these libs:

  • MiMa checking that's smart about whether the binary compatibility is intentional (thus scanning commit messages for keywords indicating so)
  • automatic version setting

What I'm currently thinking is:

  • Scan commit for keywords indicating whether binary breaking change is expected
  • Do MiMa check if binary compatibility should be maintained
  • Bump the version correctly (if breaking change is intentional, bump the major version otherwise minor/patch)

I think I can further set ThisBuild / version in my project settings (overriding sbt-dynver's) and use my own version bumper. MiMa can be similarly disabled if bin compat is detected to be intentionally broken.

Christof Nolle
@nolledge
Hi, I use dynver in many projects. Now I am facing an 'issue' (more on a "nice to have"-level) when assembling a jar and running it. In one place I expose the version of an API with sbt-buildinfo. The created artifact can not obtain information from git and therefore the version formatted like HEAD-TIME. It should be enough to somehow create a version.sbt during assembly, right?
Dale Wijnand
@dwijnand
That shouldn't be necessary, as sbt-buildinfo should capture the information as a string. So it sounds like the problem is in how you've set up sbt-buildinfo, maybe? Can you share the setup you have?
Christof Nolle
@nolledge
oh I think I know now what the problem is :) I assemble the application in a docker container '.dockerignore' should probably not contain .git
thanks for your help @dwijnand
Dale Wijnand
@dwijnand
hehe, np