Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 2015 11:10
    japgolly commented #2066
  • Jun 22 2015 08:25
    keepscoding commented #2044
  • Jun 21 2015 03:24
    xerial commented #157
  • Jun 21 2015 00:10
    eed3si9n unlabeled #2057
  • Jun 21 2015 00:10

    eed3si9n on 0.13

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 3 more (compare)

  • Jun 21 2015 00:10
    eed3si9n closed #2057
  • Jun 21 2015 00:10

    eed3si9n on fixbuild

    (compare)

  • Jun 20 2015 18:42
    eed3si9n synchronize #2057
  • Jun 20 2015 18:42

    eed3si9n on fixbuild

    Fix typo (compare)

  • Jun 20 2015 18:23

    eed3si9n on fixbuild

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 1 more (compare)

  • Jun 20 2015 18:23
    eed3si9n synchronize #2057
  • Jun 20 2015 14:59

    eed3si9n on scalaversionbump

    (compare)

  • Jun 20 2015 14:59

    eed3si9n on 0.13

    Bumping up Scala version to 2.1… Try to keep bincompat Fixes #1666 and 1 more (compare)

  • Jun 20 2015 14:59
    eed3si9n unlabeled #2068
  • Jun 20 2015 14:59
    eed3si9n closed #2068
  • Jun 20 2015 14:59
    eed3si9n closed #1666
  • Jun 20 2015 14:57
    eed3si9n commented #2068
  • Jun 20 2015 12:55
    dwijnand commented #2068
  • Jun 20 2015 04:51
    eed3si9n synchronize #2068
  • Jun 20 2015 04:51

    eed3si9n on scalaversionbump

    Fixes #1666 (compare)

OlegYch
@OlegYch
according to semver x.y.z+1 is strictly superior to x.y.z
Ryan Williams
@ryan-williams
not sure what "strictly superior" means here? i have seen many examples in the wild where taking a dep's newer version results in RTEs
OlegYch
@OlegYch
according to semver patch versions are fixing bugs
of course maven or whatever don't know about semver, so you might actually pull incompatible version
but it might as well be forward-incompatible
so either way stuff breaks
eg a lib requires guava 24, and you have guava 18 in your project
if you pick 18 the lib breaks
Ryan Williams
@ryan-williams
technically, no, it depends what code paths you hit at runtime
OlegYch
@OlegYch
if you pick 24 there is a good chance your project will work
Edmund Noble
@edmundnoble
@ryan-williams Semver requires that a new minor version cannot result in an RTE.
Otherwise they are doing semver incorrectly.
OlegYch
@OlegYch
especially since you can verify that
because tests and compiler, you know
which you typically can't run for the library
(to test if it still works with guava 18(
Ryan Williams
@ryan-williams
@edmundnoble today I had a project RTE against hadoop 2.6.0 but work on 2.7.3. do you think they are doing semver incorrectly?
Edmund Noble
@edmundnoble
No. That's not what @OlegYch is saying.
2.6.0 vs 2.6.1 should work.
I may be misspeaking; I suppose the last digit is not minor version.
Ryan Williams
@ryan-williams
yes, that is the "patch" version
Edmund Noble
@edmundnoble
Ah yes, just took a look.
Yeah, that's what Oleg is referring to above with "x.y.z+1" vs "x.y.z".
Ryan Williams
@ryan-williams
i understand
eugene yokota
@eed3si9n
some links on Maven vs sbt (Ivy) - sbt/sbt#2954
Maven uses nearest-wins algorithm on conflict
OlegYch
@OlegYch
  1. that 2.x is a minor version 2. you have rtes with downgraded version, which is exactly what i'm warning against
eugene yokota
@eed3si9n
Ivy uses latest-wins, but it encodes pom.xml with force(), which emulates nearest-wins
Ryan Williams
@ryan-williams
nearest-wins, thanks @eed3si9n, this is exactly what i was looking for
OlegYch
@OlegYch
isnt that specific to version ranges?
which are a big no-no
eugene yokota
@eed3si9n
it's to resolve conflict in general iiuc
OlegYch
@OlegYch
anyway, it would be interesting to see your sample project
utterly bizarre tbh
eugene yokota
@eed3si9n
yea. it would have been better if the notion of API compatibility was encoded into pom or ivy files
which leads to Adept, which leads to some tool that can extract JARs and treat them as sets of functions
OlegYch
@OlegYch
sounds nice
Ryan Williams
@ryan-williams
@eed3si9n what's Adept?
OlegYch
@OlegYch
i think unison attempts to do that
eugene yokota
@eed3si9n
Adept is the notion I mentioned at nescala of storing metadata of API compatibility in a Git-like thing on the side - https://www.slideshare.net/ekhfre/introducing-adept
http://adepthub.com/ says "Welcome to nginx!"
Ryan Williams
@ryan-williams
haha, cool, i remember you mentioning this now, thanks
Ryan Williams
@ryan-williams

an interesting wrinkle to semver-based heuristics: minor-version-upgrades cannot cause any new code paths in dependencies to be hit (without risking the same kinds of RTEs that major-version-upgrades can cause).

Suppose:

  • A:1.0.0 uses some library B:1.0.0
  • A:1.1.0 also uses B:1.0.0
  • A:1.1.0 exercises some code path X in B:1.0.0 that A:1.0.0 never uses
  • Library C uses A:1.0.0, and also B:2.0.0, which removed X.
  • C upgrades from A:1.0.0 to A:1.1.0, now gets RTEs (when its calls to A hit X) despite only having performed a minor-version upgrade.

semver is not obviously super clear on this from my reading:

MAJOR version when you make incompatible API changes,

that doesn't really seem to cover this scenario

MINOR version when you add functionality in a backwards-compatible manner

this could be interpreted as covering this scenario, but most ppl don't seem to interpret it that way, and the "MAJOR version" rule seems to miss it…

eugene yokota
@eed3si9n
B:1.0.0 and B:2.0.0 are incompatible so C can't use it
but if we do away with numbering system, we end up with "some tool that can extract JARs and treat them as sets of functions" that I mentioned above
Ryan Williams
@ryan-williams
agreed, i'm just chewing on what we could/can't get from some ideal semver-aware resolver :)
interesting point that a semver-aware resolver could at least flag the above scenario as invalid; however, that same resolver would flag the previous scenario, where A was happily depending on B:1.0.0, as invalid as well, which I'd call a false-positive
OlegYch
@OlegYch
sbt flags, at least in some cases
but semver is not nearly enough