Fork me on GitHub
#clojure-dev
<
2020-02-19
>
seancorfield04:02:30

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

seancorfield04:02:35

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

alexmiller04:02:31

It’s just work I have no reason to do

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

alexmiller04:02:09

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

seancorfield04:02:31

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

seancorfield05:02:07

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

seancorfield06:02:03

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

alexmiller13:02:02

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

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

alexmiller13: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)

alexmiller13:02:47

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

seancorfield18:02:07

Good to know. What does parent 0.3.0 bring in?

seancorfield18:02:35

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

seancorfield18:02:18

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

alexmiller18:02:39

0.3.0 and 1.0.0 are the same

alexmiller18:02:06

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

alexmiller18: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 http://build.ci project

alexmiller18:02:41

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

dpsutton18:02:02

which affects the bytecode version in the production artifact?

seancorfield18:02:06

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

alexmiller18:02:11

there is no bytecode in the artifact

alexmiller18:02:24

by default all contrib libs are source jars

alexmiller18:02:36

so starting over...

dpsutton18:02:37

oh of course. whoops 🙂

alexmiller18:02:51

the parent pom includes a property clojure.version

alexmiller18:02:07

that property is used to bring in a dependency on Clojure

alexmiller18:02:37

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

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

alexmiller18:02:53

the http://build.ci 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)

alexmiller18: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)

alexmiller18:02:35

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

alexmiller18:02:08

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

seancorfield18:02:15

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.

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

alexmiller18: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)

alexmiller18:02:53

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

alexmiller18:02:07

clojure 1.8 was down to 10%

👀 1