2

When you use maven, ivy2, or sbt to manage your package dependencies, there are plenty of techniques to let you see which packages versions depend on other package versions and to see which ones evict others.

For example, one useful tool to view existing dependencies when using sbt and scala is sbt-dependency-graph

But when you are looking to upgrade to newer packages, how can you find a combination that will work?

Are there tools to search for those combinations?

Are there systematic and, hopefully, efficient manual ways to search?

When using sbt and scala, this gets even harder because the compiler version is often part of the package identifier.

Please let us know your tips for moving to new newer package versions.

Traveler
  • 1,048
  • 14
  • 27
  • Good question. I always annotate my dependencies with a comment containing the project URL, then manually check each at the start of a sprint. :) – joescii Feb 09 '14 at 02:02
  • @barnesjd I upvoted for you. – som-snytt Feb 09 '14 at 07:10
  • Can you elaborate on what you mean by: "a combination that will work". Do you mean a combination of dependencies where the conflict resolution strategy in Ivy results in compilation and no runtime exceptions? If so, that sounds like a process that cannot be automated. – Dave Swartz Feb 09 '14 at 15:45
  • When I wrote this, I had in mind simply walking the graph and finding new released point versions. But your point is a good one that it won't reveal compatibility issues. I suppose a tool could do a form of collective intelligence by examining the universe of released packages (poms) to infer that as a vote for compatibility. Then coalesce them into a set of versions that are as advanced as they can be? – Traveler Feb 09 '14 at 16:38

1 Answers1

2

I'll admit that I'm not sure if it ensures all the versions are compatible but sbt-updates will tell you which dot, minor, and major version upgrades are available for your dependencies.

yǝsʞǝla
  • 16,272
  • 2
  • 44
  • 65
Leif Wickland
  • 3,693
  • 26
  • 43
  • Thank you, Leif. I tried it and it works. I will wait a little bit before accepting to see if anything else pops up. – Traveler Feb 09 '14 at 16:58
  • Nice... I'll definitely look at that when we start our next sprint! ;) – joescii Feb 09 '14 at 18:41
  • @barnesjd I'd be really curious what your experience is with upgrade compatibility. Having a nice defined process around staying on top of dependency upgrades each sprint seems really useful. – Leif Wickland Feb 10 '14 at 16:36
  • 2
    @LeifWickland We have only done it for two sprints, but thus far it is working well. We always do it at the start of the sprint, so you have time to figure out something doesn't work. If it's a minor version change, we'll usually bump it without second thought. If it's a major, then we'll investigate the changes to determine if it's an easy upgrade. We don't take snapshots, milestones, or release candidates. Any time there is a reason we aren't upgrading, we put an in-line comment with the dependency so we don't forget. – joescii Feb 10 '14 at 19:06