Closed teodorlu closed 1 year ago
Looks like the CI failures above were:
I think I've got it working now.
For git deps, I skipped some work. If the same version as the current version is found, we don't upgrade.
@borkdude I'm happy with this PR now. Mind taking a look?
@teodorlu Thanks. I've been thinking, perhaps we could also have an --unstable
flag to upgrade to the latest unstable version?
Agreed, an --unstable
flag would be useful!
Added support for --unstable
in #188.
Note: the latest version whatsoever is picked, so if a stable version is the latest version, that stable version will still be picked.
[x] This PR corresponds to an issue with a clear problem statement.
180
[x] I have updated the CHANGELOG.md file with a description of the addressed issue.
A fresh take on #179 , moving slower and leaning more heavily on tests for development.
I added a
:dev
alias todeps.edn
for working with tests from the REPL. I can remove it if needed.I also made some changes to existing tests, and added some new one. I think it's easier to understand what the code does from reading the tests now.
For a library with the following available versions:
1.0.1-alpha1
,1.0.1-alpha2
,1.0.1
,1.0.2
,2.0.0-alpha1
,2.0.0-alpha2
, before this PR, we would see this behavior:1.0.1-alpha1
is upgraded to1.0.2
1.0.1
is upgraded to1.0.2
2.0.0-alpha1
is not upgradedAfter this PR, we would see this behavior:
1.0.1-alpha1
is upgraded to1.0.2
(unchanged)1.0.1
is upgraded to1.0.2
(unchanged)2.0.0-alpha1
is upgraded to2.0.0-alpha
(new behavior)