Fork me on GitHub
#announcements
<
2020-02-18
>
alexmiller15:02:49

InsideClojure - 1.0 all the things https://insideclojure.org/2020/02/18/lib-version/ - please read if you maintain a Clojure lib (discussion to #clojure)

👍 84
🎉 4
gerred15:02:09

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
gerred15:02:24

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

gerred15:02:57

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.

dchelimsky15:02:48

@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
vlaaad15:02:28

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

dchelimsky15:02:59

For the next few hundred years, sure 😉

gerred15:02:10

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"

gerred15:02:09

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: https://github.com/kudobuilder/kudo/blob/master/keps/0019-package-api-versioning.md

gerred15:02:51

i digress. 😄 thanks @U064X3EF3 for the post!

alexmiller15: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
alexmiller21: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 • data.zip 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
alexmiller21:02:04

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

gerred23:02:57

or as before, clarification of version policy 😉

alexmiller23:02:32

Sure, will loook at it later

beders07:02:52

It’s a good thing. Well done

rickmoynihan09:02:02

just a minor FYI: the test.check changelog hasn’t been updated: https://github.com/clojure/test.check/blob/master/CHANGELOG.markdown

alexmiller13:02:45

@U05509S91 released transit-java and transit-clj yesterday

gerred13:02:59

thank you sir!

avocade14:02:12

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
avi15:02:04

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?

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

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

alexmiller15:02:31

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

avi15:02:56

Ah, I see. Makes sense. Thanks!

gerred21:02:00

@U04V70XH6 literally just updated this 😂

seancorfield21:02:38

@U05509S91 tools.cli is going to get multi-valued option arguments per https://clojure.atlassian.net/browse/TCLI-96 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.

seancorfield21:02:15

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). java.data got a 1.0.x release yesterday. I think that covers everything I maintain directly in Contrib.

gerred21:02:53

yup makes sense

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

gerred22:02:29

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

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

alexmiller22:02:32

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

gerred22:02:54

yeah for sure

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

gerred22:02:04

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

gerred22:02:10

¯\(ツ)