Fork me on GitHub

This PR has been open for almost a month: 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. /cc @plexus


I added you as a reviewer @borkdude


And I totally agree, we shouldn’t let them hang.


approved PR


I should probs make this auto-deployable as well.


That would be nice. I see its still using the flatland org, is that right?


gah! That makes it harder to make it auto-deployable 😕


(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.*)


we could just normalize every library to do this


No conscious choice on my side, I only remembered the io.github thing.


yeah, not important I guess


gah, tests are failing.


that's interesting


it seems those tests were failing for a while already


Yes, which is even more annoying.


Do they run locally?


I'll try it as well


at least lein test works


I can reproduce the error with lein with-profile +1.6 test


probably this should be with-profiles plural


it seems the tests work from Clojure 1.8 onwards


let's just drop support for older Clojure versions. people should just upgrade ;)


seems like some other discussion I’ve seen lately…


you mean in rewrite-clj?


I don't think it's unreasonable to only go back one or two major versions. People can still use the old one.


You shouldn't have to backport every damn single predicate in core ;)


Also, nudging people to upgrade Clojure for newer features in libraries isn't a bad thing either I think


I believe there is a PR for this now.


And I believe it was approved 🙂


@slipset ah it seems the circleci config still has lein with-profile +1.7 test etc


D’oh, so Circle wasn’t running testall 😕


New commit 😕


thanks for the merge @borkdude!

🎉 2

and @plexus for actually doing the work 🙂


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


but I'm not against it


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

Alex Miller (Clojure team)12:09:47

state of clojure data is useful for making decisions like this Q18 shows 1.3% using Clojure 1.7.x or earlier and Clojure 1.8 use 6.4% (this is a multi-select question).





1.7.0 or earlier


@alexmiller Perhaps an interesting question for the survey: what's preventing you from upgrading to the latest (except for intertia)

Alex Miller (Clojure team)13:09:39

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

👍 2

And maybe people who don't bother to upgrade to new versions of Clojure also don't bother to answer Clojure surveys.

Alex Miller (Clojure team)13:09:19

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!


Thanks, I’m interested in the answer to that too!


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.

👍 2

I'll add this data to the issue! Muchos gracias for the chat.


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.


then don't upgrade the tooling? ;)


That's a good question, if you are updating libs, why wouldn't you also update Clojure?


But we will have the same issue when comes out with spec2.


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?


I mean, if your tooling pulls in newer clojure


There’s another aspect to it. At work, I from time to time have to interact with the javascript frontend sources. Every time I have to do 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.


The only thing I really wanted to do was yarn start


let's not talk about yarn or node.


completely different ecosystem


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


so I would like to have real scenarios, not hypothetical ones


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. simple_smile


@alexmiller I had a quick look at support matrixes for Clojure core team lib builds. For example, They seem to cut off testing at Clojure v1.8, is that typically right?

Alex Miller (Clojure team)15:09:23

I have declared it to be "right" :)

simple_smile 2
Alex Miller (Clojure team)15:09:52

many libs also work with older versions, but we do not test those combos

Alex Miller (Clojure team)15:09:06

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

Alex Miller (Clojure team)15:09:46

moving to a different disk is possible but is a fair amount of effort that I am trying to delay into the indefinite future

Alex Miller (Clojure team)15:09:02

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?

Alex Miller (Clojure team)15:09:41

I would tell you to lock to an older version of the lib if you need that


Thanks, that helps!

Alex Miller (Clojure team)15:09:51

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)

👍 2
Alex Miller (Clojure team)15:09:09

if you're curious, the CI jobs are generated (by some Clojure of course) from the data here:


Oh cool! Thanks!


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 *assert* :P


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.

Alex Miller (Clojure team)15:09:15

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)?


This is more like validation in development which can be turned off.

Alex Miller (Clojure team)15:09:03

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)

Alex Miller (Clojure team)15:09:58

but the intent is the same - assert in dev, not in prod

👍 2
Alex Miller (Clojure team)15:09:47

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?

👍 4

This is helpful, I like this, although I already knew this from your ClojuTRE talk, it's good to see it again.


It would be cool if issue trackers supported this

Alex Miller (Clojure team)15:09:13

yeah, we've given up making the table anywhere but in a spreadsheet


Hammock ™️ , the JIRA / Github issues killer


with built-in spread-sheets

Alex Miller (Clojure team)15:09:01

^^ this is how we answer questions like this in the core team

Alex Miller (Clojure team)15:09:08

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