Fork me on GitHub
Alex Miller (Clojure team)15:02:49

InsideClojure - 1.0 all the things - please read if you maintain a Clojure lib (discussion to #clojure)

👍 84
🎉 4

thanks for this @U064X3EF3. maybe a bit parallel to the thoughts here. what I did appreciate is how @U0ENYLGTA laid out exactly the versioning scheme that aws-api and service packages use. I agree with what you're saying there, I would suspect it's a lot of people defaulting to what they see in other ecosystems, even prior to semver, when they see 0.x. with that aws-api versioning scheme well known, I wouldn't particularly care if it was 0.x or 1.x or 2.x or whatever.

👍 4

heck, a lot of projects (see the ill-fated CoreOS) use time since their epoch for versions


to avoid parroting you further, gets me thinking about for my projects writing a "Versioning Scheme" section in the readme, even if it's only a sentence or two, to make it obvious why a version changes when it does.


@U05509S91 that would be great. There seems to be an expectation that Semver is the default. Being explicit about it (even if what you're saying is "we do semver" is a good thing IMO.

👍 4

having version like v2020.02.18 seems clear enough an indicator that it’s not a semver


For the next few hundred years, sure 😉


even in that (ok, expand to versioning policy) - it's nice to know the policy around those versions if there is one, or that it's just "date when we kicked this out to maven"


not to make anyone stare into the void of Kubernetes and turn to stone, but over in our operator project we have an entire enhancement proposal around how we version:


i digress. 😄 thanks @U064X3EF3 for the post!

Alex Miller (Clojure team)15:02:42

I'm adding this to contrib lib readmes as I change them: "This project follows the version scheme MAJOR.MINOR.COMMITS where MAJOR and MINOR provide some relative indication of the size of the change, but do not follow semantic versioning. In general, all changes endeavor to be non-breaking (by moving to new names rather than by breaking existing names). COMMITS is an ever-increasing counter of commits since the beginning of this repository."

💯 24
👍 28
Alex Miller (Clojure team)21:02:44

Per the previous post, there are some new contrib releases today: • core.async 1.0.567 • tools.gitlibs 1.0.83 • data.csv 1.0.0 • data.json 1.0.0 • core.logic 1.0.0 • core.match 1.0.0 • 1.0.0 • java.classpath 1.0.0 • tools.namespace 1.0.0 • data.generators 1.0.0 • test.generative 1.0.0 • data.priority-map 1.0.0 • java.jmx 1.0.0 • test.check 1.0.0 • data.fressian 1.0.0 • tools.analyzer 1.0.0 - thanks Nicola! • tools.analyzer.jvm 1.0.0 - thanks Nicola!

👍 176
💯 96
😂 64
1️⃣ 12
😁 4
🐙 8
Alex Miller (Clojure team)21:02:04

and prob a few more over the coming days, but that's mostly it


or as before, clarification of version policy 😉

Alex Miller (Clojure team)23:02:32

Sure, will loook at it later


It’s a good thing. Well done


just a minor FYI: the test.check changelog hasn’t been updated:

Alex Miller (Clojure team)13:02:45

@U05509S91 released transit-java and transit-clj yesterday


thank you sir!


Hehe love it. There's always a different between what's right (`semver is borked`), and what's otherwise conventional in the "business" (e.g. what clojure newbies will assume). Good call 🙂

🐙 4
sheepy 4

Just curious… if the new versioning scheme is MAJOR.MINOR.COMMITS then why do almost all of these version identifiers have a third segment that’s 0?

Alex Miller (Clojure team)15:02:53

older projects started that way and it's been easier to just retain that than move to the commit scheme (which currently requires a manual step)

Alex Miller (Clojure team)15:02:34

on the infinite todo list is better automation that works with the contrib build box setup, and then it would be easier to move to that

Alex Miller (Clojure team)15:02:31

I've updated readme's on those projects above as I released to describe the version scheme (whichever it is)


Ah, I see. Makes sense. Thanks!


@U04V70XH6 literally just updated this 😂


@U05509S91 tools.cli is going to get multi-valued option arguments per and then it will be released as 1.0.x; core.cache and core.memoize also have 1.0.x releases coming -- Fogus and I are collaborating on those.


java.jdbc will stay at 0.7.11 because seancorfield/next.jdbc is essentially the 1.0.x release of that (with a different API). got a 1.0.x release yesterday. I think that covers everything I maintain directly in Contrib.


yup makes sense

Alex Miller (Clojure team)21:02:27

any contrib lib not yet 1.0 is either lightly used and non-critical or the process for getting there is in the hands of project owners and will happen in due time as seen fit


makes sense. I'm just calling out ones that I actively touch as I touch them, happened to be doing some arg parsing and figured I'd throw in the note. 🙂

Alex Miller (Clojure team)22:02:52

in addition to the ones just mentioned, tools.logging and data.xml are others that could potentially be updated. the latter in particular has been in perma-alpha for a long time

Alex Miller (Clojure team)22:02:32

tools.deps.alpha is definitely headed there, but has more decisions about being non-alpha named


yeah for sure

Alex Miller (Clojure team)22:02:14

other than those, I'm not planning on actively doing any more, but other owners of less frequently active libs may get to them at some point (like math.combinatorics or something)


for those there may not even be a reason (arguably) to kick out another version unless there's an actual change in the package itself