2 ms·

This is just an excellent comment, thank you. One note - we're not as concerned with predicting exactly the user's build as I think your $DAYJOB might be. We n

This is just an excellent comment, thank you. One note - we're not as concerned with predicting exactly the user's build as I think your $DAYJOB might be. We need to scan the space of possible valid resolutions that'd do a big framework upgrade, then pick an optimal (least effort) option from that space and chart your path towards it. Concretely that'll mean opening incremental PRs against your codebase where we provide lockfiles that are individually valid and accumulate in getting your upgrade done.

ilikebits 3y ago
> where we provide lockfiles that are individually valid Providing lockfiles is a really interesting idea! That certainly solves the "we need your non-deterministic build tool to reproduce an exact build that we found" problem. We haven't explored this route yet because a lot of our customers use tools that don't support lockfiles (e.g. Maven - Java in general has a lot of legacy stuff). If you want to build off of our work, our dependency analysis bit is open source: https://github.com/fossas/fossa-cli https://github.com/fossas/fossa-cli
- erik_seaberg 3y ago
  Maven POM dependencies act as version pins, until you run versions:resolve-ranges to bump them. The only exceptions would be using a SNAPSHOT version (where each build gets a timestamp and is only cached briefly) or your Maven repo admin replaces the contents of a pre-existing artifact (and you'll see a lot of cached checksum warnings about it).