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

neil dep add: Prefer stable versions #146

Closed
rads opened this issue Jan 21, 2023 · 9 comments
Closed

neil dep add: Prefer stable versions #146

rads opened this issue Jan 21, 2023 · 9 comments

Comments

@rads
Copy link
Collaborator

rads commented Jan 21, 2023

I think installing a stable version is what most users want in the end.

Current behavior:

$ cat deps.edn
{:deps {}}

$ neil dep add nrepl

$ cat deps.edn
{:deps {nrepl/nrepl {:mvn/version "1.1.0-alpha1"}}}

Expected behavior:

$ cat deps.edn
{:deps {}}

$ neil dep add nrepl

$ cat deps.edn
{:deps {nrepl/nrepl {:mvn/version "1.0.0"}}}
@borkdude
Copy link
Contributor

I don't agree on this one. There are some libraries like hiccup and clojure.data.xml which have been using alpha versions for years and everybody uses those.

@rads
Copy link
Collaborator Author

rads commented Jan 21, 2023

Fair enough. Personally I think it's bad practice to encourage the use of alpha versions as the default for all dependencies. If there's a library that everyone uses as an alpha, that should be the exception rather than the rule. It seems like the ideal behavior would be to install stable versions by default and allow for overrides for specific libraries where the alpha versions are preferred.

I've been trying to use neil dep add but in the end it's faster for me to just look it up in my browser since I want the stable version in 99% of my own use cases. If I asked someone on my team to set up a project and their pull request had a deps.edn full of -alpha versions, I'd ask them to go back and switch them to the stable versions unless it's absolutely necessary. That just seems like common sense for security and stability.

Feel free to close this or move to a discussion, whatever you prefer.

@borkdude
Copy link
Contributor

@rads Yes, I think you're right, these deps should be the exception. As long as neil doesn't downgrade them to stable versions once you have set them to alpha, it should be good. Might also be good to check what other tools like antq do here?

@borkdude
Copy link
Contributor

@rads Just FYI, I changed my mind on this and I agree that this should be addressed, as long as existing alpha versions aren't downgraded to stable versions (because that would be annoying for things like hiccup and clojure.data.xml).

@rads
Copy link
Collaborator Author

rads commented Jan 26, 2023

@borkdude: Thanks for letting me know! I apologize if any part of my previous comment came off as snarky. I just want to make sure I get my point across as concisely as possible but also acknowledge it's your decision so we don't have to waste time going back and forth on issues where we may disagree.

@borkdude
Copy link
Contributor

Not at all, no problem

@KingMob
Copy link
Contributor

KingMob commented Jan 27, 2023

Where do -SNAPSHOT versions fall in this? Currently, neil dep upgrade --dry-run is trying to replace a newer 0.4.2-SNAPSHOT with an unwanted 0.4.1 in my deps.

@KingMob
Copy link
Contributor

KingMob commented Jan 27, 2023

I see this is partially mentioned in #145 , but I think it should be considered for upgrade purposes as well.

@borkdude
Copy link
Contributor

I'd say the behavior should be "never downgrade".

Perhaps we can use version-clj to do the version comparisons:

https://github.com/xsc/version-clj

(and lazily load it for good startup time).

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