This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # announcements (6)
- # babashka (8)
- # beginners (134)
- # calva (18)
- # chlorine-clover (1)
- # cider (6)
- # circleci (6)
- # clj-commons (111)
- # cljsrn (13)
- # clojure (95)
- # clojure-australia (2)
- # clojure-europe (15)
- # clojure-nl (1)
- # clojure-spec (52)
- # clojure-uk (17)
- # clojurescript (4)
- # datavis (9)
- # datomic (8)
- # docker (2)
- # emacs (15)
- # events (7)
- # fulcro (6)
- # graphql (1)
- # gratitude (1)
- # introduce-yourself (2)
- # kaocha (8)
- # meander (87)
- # minecraft (2)
- # music (2)
- # off-topic (20)
- # portal (119)
- # releases (1)
- # reveal (55)
- # shadow-cljs (34)
- # sql (36)
- # tools-deps (9)
- # vim (8)
- # xtdb (39)
This PR has been open for almost a month: https://github.com/clj-commons/ordered/pull/59 What can we do to speed up merging if the PR is considered OK? I don't think outside contributors will find clj-commons attractive to contribute if PRs are left hanging, that's what I'm slightly worried about.
Full disclosure: I would like to see
ordered well maintained since clj-yaml uses it and via that library
ordered is used in #babashka, this is my personal interest.
If I can do anything to help, let me know.
(and if we were to change, we’d need to change it to
io.github.clj-commons because of the clojars restriction 😕
I'd be fine with that (or the com.github.clj-commons one, I don't understand the choice for io.*)
I don't think it's unreasonable to only go back one or two major versions. People can still use the old one.
Also, nudging people to upgrade Clojure for newer features in libraries isn't a bad thing either I think
Heya, about rewrite-clj v1 and supporting old Clojure versions. Supporting back to v1.8 seems reasonable, yeah?
if you ask me 1.9 is already reasonable enough, especially now that it's hosted under a different org which means people have to upgrade to a "different" lib anyway
just note that maintaining support for older clojure versions comes with ... more maintenance
and upgrading clojure... is that really such a big deal? it's a poster child of stability
state of clojure data is useful for making decisions like this https://www.surveymonkey.com/results/SM-S2L8NR6K9/ Q18 shows 1.3% using Clojure 1.7.x or earlier and Clojure 1.8 use 6.4% (this is a multi-select question).
@alexmiller Perhaps an interesting question for the survey: what's preventing you from upgrading to the latest (except for intertia)
I think the answer is probably: nothing - they are supporting older for backwards compatibility. given how quickly people move to new versions, this is probably not an interesting enough question to include
And maybe people who don't bother to upgrade to new versions of Clojure also don't bother to answer Clojure surveys.
but they do bother to update misc libs?
btw isn't this a chicken/egg problem? people are using 1.8 because they want to support it, and we are looking at how many people are still using 1.8?
Ha! The people using 1.8 are using it only to offer support for 1.8? Twisted! I like it!
One case here: https://www.reddit.com/r/Clojure/comments/pu4nk0/keyword_not_equal_to_itself/he0jxkh/?utm_source=reddit&utm_medium=web2x&context=3
Thanks guys, that helps very much. I support back to 1.9 now but had some very strong interest from a user of rewrite-clj to support older versions. I agreed to back as far as 1.8.
FYI that one user is quite heavily invested in tooling, so I kind’a get his point. It would be a nuisance to have to upgrade your thing that’s been running for ages just because you upgraded your tooling.
That's a good question, if you are updating libs, why wouldn't you also update Clojure?
I guess my use case could be that I have multiple projects that I maintain, and one of them is stuck on 1.8 for some reason (and I work on it rather seldomly), the others I keep current and my tooling as well. I’m not saying this is a very common situation, I’m just trying to find the examples.
this comes back to the question: is there a real situation where upgrading clojure makes your old software crash?
yarn install and some times I have to install a new versjon of node and a new version of yarn. All I wanted to do was to get the frontend up and running.
Fair, but my point being that you came here to do one thing, and then suddenly, because of reasons, you have to start upgrading stuff.
The way I see it is that your tooling already upgraded Clojure for you (as their minimum requirement) and this should never break your old Clojure program
Then I apologise for not understanding the intricacies of tooling (which I probs should have understood)
I think an example given was some tooling brought into the same process as your app. Your app is on an old version of Clojure but some library in the tooling requires a newer version of Clojure.
I have encountered one such example in the past where someone tried to run clj-kondo in Light Table which for some reason was using clojure 1.8 (I hadn't looked into why it was locked on that)
but perhaps that's a tooling problem: you should never be locked into one version of clojure because your tooling chooses that?
The scenario that lread is describing should not be problematic: upgrading Clojure should "just work"
Sounds reasonable, but I would imagine (way out of my comfort zone) that stuff like nrepl middlewares and stuff need to run the same version as your project?
Yes sure. But pulling in a newer Clojure should "just work" with your tooling. Why not?
An irony for me is that rewrite-clj v0 did not care nearly as much about not making breaking changes as I have for rewrite-clj v1.
@alexmiller I had a quick look at support matrixes for Clojure core team lib builds. For example, https://build.clojure.org/job/core.cache-test-matrix/. They seem to cut off testing at Clojure v1.8, is that typically right?
that is what we do
I have declared it to be "right" :)
many libs also work with older versions, but we do not test those combos
the combination of libs x clojure versions x java versions x build history defines a quantity of disk space, which is finite on the box we are on
moving to a different disk is possible but is a fair amount of effort that I am trying to delay into the indefinite future
Clojure 1.8 came out 5.5 years ago, seems like a reasonably old time horizon to test
If a change to a core lib was discovered to have broken compat for Clojure < v1.8, would you consider that to be a problem?
I would tell you to lock to an older version of the lib if you need that
you can "solve" this problem either by making it trivial to live in a reproducible past (see: Go) or by making it easy to move forward to the present by minimizing or eliminating breaking changes (Clojure)
if you're curious, the CI jobs are generated (by some Clojure of course) from the data here: https://github.com/clojure/build.ci/blob/master/ci_data.clj
Thanks for a very interesting and civil discussion to all! I realize folks can have strong feelings on this topic.
Now we're making progress, perhaps also ask Alex's opinion on making a custom
The use case: a user is concerned that his tooling users disable
*assert* so the error reports are becoming less readable. To circumvent this he wants to introduce a library custom assert which his tooling always forces to true.
I'm not sure why my opinion is relevant here, but assert is designed to be turned off. if you need something to always be on, it's not an assertion, it's data validation and doesn't need to be conditional.
@alexmiller what about clojure.spec: this is also data validation (in part) and designed to be turned off in production (in some environments)?
spec has its own assertion system because it had constraints that could not be satisfied by the existing one (completely compiling out the spec validation)
but the intent is the same - assert in dev, not in prod
what problem are you trying to solve: error reports don't have enough info alternatives: • ask users to turn on assertions when sending reports • make assertions non-conditional • add a new flag for validation and default to on • ??? brainstorm a few more minutes and you might think of some more comparison criteria: • quality of error reports • performance in prod • configuration complexity • ??? brainstorm some more to compare, make a table: put the alternatives on top, put the comparison criteria on the left. fill out the table with the best data you have, do work to fill in unknown squares color squares based on how well they satisfy the criteria are two columns mostly the same? if so, come up with new criteria to differentiate them is some column mostly green? it's probably a good answer. are the not-green cells fatal? can they be mitigated?
This is helpful, I like this, although I already knew this from your ClojuTRE talk, it's good to see it again.
yeah, we've given up making the table anywhere but in a spreadsheet
^^ this is how we answer questions like this in the core team
it is of course, a process with cycles. you may go back to the problem and/or alternatives and/or comparison criteria as you learn more