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. /cc @plexus

I added you as a reviewer @borkdude

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

approved PR

merged

awesome

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

nope

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?

yup

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!

and @slipset :)

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

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

1.10.x
94.02%2,203

1.9.0
11.65%273

1.8.0
6.36%149

1.7.0 or earlier
1.28%

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

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.

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 1.next 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.

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

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

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.

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.

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