Fork me on GitHub

@alexmiller Q re: the 1.0.x versions we're moving to -- I see some repos are MAJOR.MINOR.COMMITS and some are MAJOR.MINOR.PATCH. That seems a bit inconsistent. Is there are reason not to move everything to the commit-based versioning?


(everyone else is welcome to pile in with pros/cons on that!)

Alex Miller (Clojure team)04:02:31

It’s just work I have no reason to do

Alex Miller (Clojure team)04:02:11

Because the commit stuff requires some manual steps, it’s much easier to screw up if you don’t do it all the time

Alex Miller (Clojure team)04:02:09

For stuff I’m not touching all the time it just doesn’t seem worth the effort


Fair enough. So there's no objection to switching tools.cli etc to MAJOR.MINOR.COMMITS if I want?


I bumped the deps in deps.edn in core.cache and core.memoize to match pom.xml 🙂 Just done the same with tools.cli and closed out one of the issues there. I also realized the parent pom has gone to 1.0.0 ("of course") so I updated all of those too...


org.clojure/ {:mvn/version "1.0.64"} is headed to Maven Central...

Alex Miller (Clojure team)13:02:02

So the parent pom thing may have effects you don’t realize

Alex Miller (Clojure team)13:02:50

It changes the default Clojure version for one thing to 1.8.0. I have only been selectively updating projects to it that already had that as the minimum

Alex Miller (Clojure team)13:02:11

Also it changes aot compilation from Java 1.6 to 1.8 - this is mostly done just to find compilation issues, not for aot release except for a couple of projects aot’ed for cljs (data.json and ...something, can’t remember the other one)

Alex Miller (Clojure team)13:02:47

But you may see differences in build or test matrix results on build box


Good to know. What does parent 0.3.0 bring in?


(core.cache and core.memoize are both supposed to be compatible back to Clojure 1.6.0)


Officially they are only backward compatible to 1.7.0 but I test them manually against 1.6.0

Alex Miller (Clojure team)18:02:39

0.3.0 and 1.0.0 are the same

Alex Miller (Clojure team)18:02:06

note that the default Clojure version does not in any way prevent it from being used with Clojure 1.6.0

Alex Miller (Clojure team)18:02:10

it affects the Clojure version used to run the release build on the build box (the test matrix is still controlled by the project

Alex Miller (Clojure team)18:02:41

lmk if what I just said does not make sense so I can clarify


which affects the bytecode version in the production artifact?


Haha... I wasn't confused before but I am now! 🙂

Alex Miller (Clojure team)18:02:11

there is no bytecode in the artifact

Alex Miller (Clojure team)18:02:24

by default all contrib libs are source jars


oh of course. whoops 🙂

Alex Miller (Clojure team)18:02:51

the parent pom includes a property clojure.version

Alex Miller (Clojure team)18:02:07

that property is used to bring in a dependency on Clojure

Alex Miller (Clojure team)18:02:37

so basically contrib libs get that by default by using the build.pom parent pom

Alex Miller (Clojure team)18:02:43

and when you run the job on the build box, that's what the tests will be run against, and what the declared dependency will be in the published pom

Alex Miller (Clojure team)18:02:53

the project defines test matrix data for what releasees to test, and that generates the test matrix job on the build box, which can potentially test both lower and higher versions than the default (it's controlled, again, by changing the value of that clojure.version property)

Alex Miller (Clojure team)18:02:13

so core.cache (using a parent pom 0.3.0/1.0.0) will depend on clojure version 1.8.0 in its published pom. a user of core.cache could declare its own dependency on clojure though at 1.6.0 and either Maven or clj is going to prefer that one (as it's a top-level dependency)

Alex Miller (Clojure team)18:02:35

that's all happy, assuming core.cache is api-compatible with Clojure 1.6.0

Alex Miller (Clojure team)18:02:08

so far, I have been conservative in making this update only on projects that already require at least Clojure 1.8.0


Thanks. I'm all clear now. May be time to drop 1.6/1.7 support in those then anyway. Will check with Fogus about it.

Alex Miller (Clojure team)18:02:06

you'll note that the matrix tests are currently for 1.7+ (that was another bump I made this week) - keeping this tight is somewhat important as the total "build all" = libs jdks clojure versions, and every build has both runtime and disk space impacts

Alex Miller (Clojure team)18:02:43

(we were real low on disk space last fall so I did a lot of cleanup. increasing the disk was going to be kind of traumatic apparently)

Alex Miller (Clojure team)18:02:53

fyi, <=1.7 usage in 2020 clojure survey was at 1.4%

Alex Miller (Clojure team)18:02:07

clojure 1.8 was down to 10%

👀 4