Improve release automation.

[samwagg]

Made these changes in consultation with @frenchy64.

• Read CTIM schema version from resources/version.edn.
• Update resources/version.edn in release automation to synchronize with lein project version.
• Add test to check that the two different version strings are the same.
• Remove defunct scripts/release.sh file (at least I'm pretty sure it's not used anymore) and update README doc.
• incidental: remove GHA schedule as it causes the workflow to be suspended after 60 days of inactivity, even for pushes and PRs!

[frenchy64]

version.edn needs to be named something more unique like resources/ctim/version.edn to avoid clashing with other (unknowable) libs on the classpath.

[samwagg]

@frenchy64 Addressed all your comments. Thanks!

[frenchy64]

This might work as-is in cljs. https://clojurescript.org/guides/ns-forms#_implicit_refer

Try removing the reader conditionals. If not, maybe we need to bump our cljs version.

[samwagg]

Okay, so this doesn't work either. I think I understand why both this and :include-macros true don't work now.

Why ':include-macros true' doesn't work
Given an ns defined in file bar.clj (note extension .clj)
Given a file foo.cljs(note extension .cljs) with the following content:

(ns foo (:require [bar :include-macros true]))

desugars to:

(ns foo (:require-macros [bar])
  (:require [bar]))

The presence of both :require and :require-macros causes the cljs compiler to look for both clj and cljs namespaces foo, but there's only the clojure one.

Why implicit refer doesn't work
IIUC, the implicit refer also only works for scenarios where there is both a clj and cljs ns (with the additional constraint that the cljs dependency ns declares :require-macros on the clj ns of the same name).

[samwagg]

So, given that the macro is defined in a plain clj ns and that we are working in a cljc file where both of the resulting clj and cljs namespaces depend on the same macro, it is necessary for the cljs ns to declare a dependency on the macro ns using only :require-macros. And the only way to achieve that (I think) is for the cljc file to have separate :clj and :cljs conditionals.

[samwagg]

Another possibility is doing it all in the same file:

(ns ctim.schemas.common
  #?(:cljs (:require-macros [ctim.schemas.common :refer [ctim-version]]))
  
...

#?(:clj
   (defmacro ctim-version
     "This is a macro to support cljs compile-time inlining of the version string
     from the JVM resource."
     []
     (slurp (io/resource "ctim/version.txt"))))

(def ctim-schema-version (ctim-version))

Which I actually don't hate. It looks a little convoluted. But I'm not sure its worse than the separate file solution. If anything it's just making the quirks easier to see.

[frenchy64]

I meant I think there's a way to avoid reader conditionals and :require-macros altogether.

i.e., instead of

(ns ctim.schemas.common
  #?(:cljs (:require-macros [ctim.version :refer [ctim-version]]))
  (:require [ctim.version :refer [ctim-version]]))

try

(ns ctim.schemas.common
  (:require [ctim.version :refer [ctim-version]]))

or

(ns ctim.schemas.common
  (:require [ctim.version :as cv]))

Failing all that, this might work:

(ns ctim.schemas.common
  (#?(:clj :require :cljs :require-macros) [ctim.version :refer [ctim-version]]))

[samwagg]

Yeah, I had tried your first suggestion. That's what I'm calling "implicit refer" (term is from that clojurescript doc) in my message above.

Your second suggestion does work fine, let's do it. I didn't realize it would let you have multiple :requires.

[frenchy64]

Can remove requires of clojure.java.io and clojure.string.

[frenchy64]

I think we always want to update the docs when we bump versions, and vice-versa.

Please redefine the "doc" alias to do the equivalent of running ctim.change-schema-version/-main followed by ctim.document/-main.

[frenchy64]

This is already recommended a few lines down. Could you consolidate them and separate the instructions so it doesn't look like you should execute them blindly top-to-bottom? I'm often in a hurry when reading this section.

[samwagg]

Yeah, I'll work on this tomorrow morning when my brain is fresh. I think there is more to do here too, such as warn about the mistakes I made when doing my release 😃 .