Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clj-kondo version scheme not recognized? #36

Open
lread opened this issue Oct 12, 2019 · 6 comments
Open

clj-kondo version scheme not recognized? #36

lread opened this issue Oct 12, 2019 · 6 comments

Comments

@lread
Copy link

lread commented Oct 12, 2019

First, a big thanks for creating this tool. I use often and very happily!

While checking on of my projects for outdated dependencies I noticed that clj-kondo was not reported as outdated.

If I take this contrived deps.edn:

{:deps {clj-kondo {:mvn/version "2019.09.22-alpha"}
        org.clojure/tools.reader {:mvn/version "1.1.1"}}}

And run:

clojure -Sdeps '{:deps {olical/depot {:mvn/version "1.8.4"}}}' -m depot.outdated.main

I get the expected result for tools.reader but nothing for the outdated clj-kondo:

|               Dependency | Current | Latest |
|--------------------------+---------+--------|
| org.clojure/tools.reader |   1.1.1 |  1.3.2 |

I noticed you are working on 2.0 (thanks! looking forward to it!), so I tried against current HEAD as well:

clojure -Sdeps \
  '{:deps {olical/depot
     {:git/url "https://github.com/Olical/depot"
      :sha "cc9e732f32a1cfb74c5427f5d36187b0dfa447e6"}}}' \
  -m depot.outdated.main

and got the same result:

Checking for old versions in: deps.edn
  org.clojure/tools.reader {:mvn/version "1.1.1"} -> {:mvn/version "1.3.2"}

As you can see on clojars, there are later versions of clj-kondo available.

I don't see anything odd in the clj-kondo versioning scheme. Just a stab, but maybe the leading zeros are an issue?

@lread
Copy link
Author

lread commented Oct 12, 2019

Ok, I pinged @borkdude with this issue and we noticed that 2019.09.22-alpha is considered as qualified, which makes sense once you know what that means.

So if we change the command line to add --consider-types:

clojure -Sdeps '{:deps {olical/depot {:mvn/version "1.8.4"}}}' \
  -m depot.outdated.main \
  --consider-types qualified,release

clj-kondo is included:

               Dependency |          Current |                    Latest |
|--------------------------+------------------+---------------------------|
|      clj-kondo/clj-kondo | 2019.09.22-alpha | 2019.10.12-alpha-SNAPSHOT |
| org.clojure/tools.reader |            1.1.1 |                     1.3.2 |

If I leave out release, I get:

|               Dependency |          Current |                    Latest |
|--------------------------+------------------+---------------------------|
|      clj-kondo/clj-kondo | 2019.09.22-alpha | 2019.10.12-alpha-SNAPSHOT |
| org.clojure/tools.reader |            1.1.1 |              1.3.0-alpha3 |

So when I consider types, am I considering types to upgrade from or types to upgrade to or both? Once I understand I would be happy to add documentation if that would help.

For clj-kondo, I like to stick to alpha releases and never move to SNAPSHOT releases, is there a way to express that? Ah, perhaps clj-kondo's 2019.10.12-alpha-SNAPSHOT is unconventional? Maybe 2019.10.12-SNAPSHOT would be the expected form?

Normally, when I look for upgrades, by default, I am interested in moving from less stable to more stable (or a later version if that is all that is available), so:

SNAPSHOT -> qualified -> later qualified -> release -> later release

would make sense. Maybe that's how depot works already, and I just don't understand yet.

@borkdude
Copy link

If this is caused by the -alpha suffix, maybe it's a good time to drop it.

@lread
Copy link
Author

lread commented Oct 13, 2019

I think that dropping alpha from clj-kondo would resolve the original issue I raised here for clj-kondo.

I think it might still be interesting to explore default upgrade paths and how —consider-types behaves for depot as depot approaches a 2.0 release.

@Olical
Copy link
Owner

Olical commented Oct 15, 2019

Hmmm, maybe this won't be fixed immediately by 2.0 but it could be changed. I really need to set aside some time to get 2.0 across the line, I'm just buried in open and non-open source work right now, struggling to find the time. Got to make sure I leave space to prepare my Clojure eXchange talk too 😬

@borkdude
Copy link

@Olical Good luck with your work and talk!

@Olical
Copy link
Owner

Olical commented Apr 11, 2021

I know this was ages ago, but if anyone is still interested in this, the latest release has a much newer version-clj dependency which may have fixed the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants