This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (43)
- # aws (28)
- # babashka (32)
- # beginners (80)
- # calva (13)
- # chlorine (2)
- # cider (11)
- # clj-kondo (15)
- # cljs-dev (1)
- # clojure (151)
- # clojure-dev (11)
- # clojure-europe (11)
- # clojure-italy (3)
- # clojure-losangeles (3)
- # clojure-nl (4)
- # clojure-spec (20)
- # clojure-uk (58)
- # clojured (3)
- # clojuredesign-podcast (2)
- # clojurescript (37)
- # core-async (4)
- # core-typed (1)
- # cursive (53)
- # datascript (5)
- # datomic (26)
- # duct (23)
- # emacs (3)
- # fulcro (22)
- # graalvm (1)
- # jobs (2)
- # joker (11)
- # juxt (24)
- # lumo (1)
- # mid-cities-meetup (2)
- # nyc (1)
- # off-topic (54)
- # parinfer (1)
- # reagent (13)
- # shadow-cljs (16)
- # sql (9)
- # tree-sitter (9)
- # vim (9)
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)
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.
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.
having version like v2020.02.18 seems clear enough an indicator that it’s not a semver
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: https://github.com/kudobuilder/kudo/blob/master/keps/0019-package-api-versioning.md
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."
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!
just a minor FYI: the test.check changelog hasn’t been updated: https://github.com/clojure/test.check/blob/master/CHANGELOG.markdown
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 🙂
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
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)
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
I've updated readme's on those projects above as I released to describe the version scheme (whichever it is)
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.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).
java.data got a 1.0.x release yesterday. I think that covers everything I maintain directly in Contrib.
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. 🙂
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
tools.deps.alpha is definitely headed there, but has more decisions about being non-alpha named
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