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

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

i digress. 😄 thanks @U064X3EF3 for the post!

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

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

@U064X3EF3 wdyt about a 1.x.x of https://github.com/cognitect/transit-clj ?

or as before, clarification of version policy 😉

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: https://github.com/clojure/test.check/blob/master/CHANGELOG.markdown

Fixed

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

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?

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)

Ah, I see. Makes sense. Thanks!

found another possible one, cc @U04V70XH6 https://github.com/clojure/tools.cli

oh

@U04V70XH6 literally just updated this 😂

nevermind

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

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.

yup makes sense

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

yeah for sure

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

¯\(ツ)/¯

correct