Maybe consider putting a leading zero in the month segment, e.g. 22.09.169, so that sorting by alphabetical order will match the chronological order?

yeah, but some systems don't support this, I've run into this with clj-kondo and the VSCode marketplace

clj-kondo uses leading zeroes

still might be good to do the leading zero thing

should we then also do the long year? 2022.09.169?

I think you would already get the compare feature by just comparing the last number, so I don't think it would complicate things much without the leading zero

22.9.169 seems good then

I'm sure @UE21H2HHD has some sensible things to add here ... :)

I guess we could also do 2209.169 ;)

but then we would break the major.minor.patch pattern

Y22.M09.R169

Sorry I derailed the discussion. 😅 On second thought I think I like your original suggestion better. You get an idea of how old a release is and you get to confuse the semantic versioning people as a bonus 😛

Exactly!

do you even need a month in the version 🤷

we don't but we don't want to break the three-segment pattern for tools that expect it

and I do like the month number to give some indication of how far someone is behind

or when I released, it's easy than just the release count number

Quite happy with the thinking so far - year & month are useful for humans, plus build number. Some projects have abandoned or not used months (graal vm 22.2.x, intellij 22.2.x, where 2 is the second biggish release of the year 22) but I do like it better with months, even though it produces longer version strings.

These version schemes are just sooo subjective. For what they are worth my ramblings: 1. Your scheme visually looks like Graal's (and clj-kondo-ish) at least for the major. 2. Graal's scheme is a little unusual but easy to get used to and strongly conveys (even celebrates) their release cadence. 3. You are always adding interesting features and breaking changes aren't a thing for this project.... so those concerns don't need to be conveyed. 4. Your patch version is high enough not be be confused with a day of the month. 5. I think your scheme suits a project with frequent updates and conveys freshness and activity. 6. It very much encourages people to keep up to date with releases, which is important for bb. So, yeah, I like it for bb!

Another date based scheme is clojure-lsp, I think it is just fine, but a bit long for me. I never read it fully and always copy and paste it. It also has that leading zero problem. This bb scheme is short enough to keep in my brain which is nice.

You could reset the release count at the beginning of each year... you'd gain a shorter version... but lose in that it could be confused with a yy.m.d and lose celebrating how many releases bb has had.

One more ramble: I'm finding I prefer predictable next versions like this scheme has. It allows me to refer to the next version in things like deprecated or added metadata if I want to. For this reason I'm no longer a fan of commit-count schemes.

yeah, so it might be good to keep the last number strictly incremental

Agree on the incremental final number. Having the month can also make it hard to predict what the next release is going to be called. If you are releasing something that relies on code that is in the dev version of bb. I can presently say "requires v0.10.164" without needing to find out when its going to be released from borkdude. With the month code in there, I can only be fairly sure if it's early in the month. This is pretty minor point. Just including it for completeness.

I like how you do it for clj-kondo 👌 2022.09.08

Yeah, but the release count won’t have leading zeroes, this is why it would be inconsistent to eg have 22.09.1144 right?

As for saying: newer than x you could say: newer than y.m.164

Perhaps we could also not include the release count and do it clj-kondo style

The only limitation is you only get one release per day lol

@U1G869VNV I often just use the next day if I must do two releases ;)

Clj-kondo style is nice too. Not celebrating your release count means a shorter version which is easier to keep in the brain. I guess keeping the leading yy future proofs you for that upcoming 4925.9.29 release. But also 2022.9.29 looks more like a date than 22.9.29. And the current year is very easy to remember. And it still is probably predictable enough, if that is of any concern for you.

You could decide what aspects are important to you and bb and weigh them against the pros and cons of version schemes.

Re-considering, since I also like the clj-kondo versioning (just data with zero padding) and the zero padding is only a limitation in the VSCode marketplace, it should not affect bb. We could do this:

2022.09.28-164

That's nice too. Dates are super easy to hold in the brain. The dash is interesting visually and makes the version easier to read. I like it. I wonder though if the dash will cause some systems will treat this version scheme differently because it looks like a qualifier (ex. 1.0.0-alpha). Clojars for example, colours its badges differently based on whether a release is 0. and/or has a qualifier (orange) else (blue). I vaguely remember https://github.com/Olical/depot not recommending releases with qualifiers... but antq has taken over in that arena... can't remember what it does here.

The -123 suffix is a common thing when you release multiple updates that should have been a single version

all libraries at cljsjs have them: http://cljsjs.github.io/

e.g. https://clojars.org/cljsjs/create-react-class

And looks like clojars colours this particular qualifier pattern as blue.

and if the suffix becomes annoying we could drop it in the future

True. I like your latest scheme.

I came up with

(defmacro with-cli-pipe-for
  [piped-field-kw [_ fn-name & defn-form]]
  (let [[params body docstring opts] (resolve-params defn-form)
        piped-field (symbol (name piped-field-kw))]
    ;; so that potentially nil opts is removed - hacky
    (remove nil?
      `(defn ~fn-name {:doc ~docstring} ~params
         ;; may result in `nil`
         ~(if opts opts)
         ;; fallback to piping if `piped-field` has no value
         (let [~piped-field (or
                              ~piped-field
                              (do
                                (println "piping!")
                                (line-seq (java.io.BufferedReader. *in*))))]
           ~@body)))))

;; 
(defn resolve-params
  "Takes parameters to a def* macro, allowing an optional docstring and opts by sorting
   out which parameter is which.
   Returns the params, body, docstring, and opts it found."
  [args]
  (let [[docstring args] (if (string? (first args))
                           [(first args) (rest args)]
                           [nil args])
        [params args] [(first args) (rest args)]
        [opts args] (if (associative? (first args))
                      [(first args) (rest args)]
                      [nil args])
        body args]
    [params body docstring opts]))

(with-cli-pipe-for :workitem-ids
  (defn test1 [{:keys [workitem-ids] :as m}]
    (prn m)
    (run! println workitem-ids)))

(with-open [is (java.io.StringReader. "1\n2\n3\n5")]
  (binding [*in* is]
    (test1 {:opt1 true})))

Gist: https://gist.github.com/MrGung/671b3476f9274ef6955bb5d4ba9fde29

@U7ERLH6JX inspired by your bb compatible badge, did you notice I created a bb built-in https://github.com/babashka/babashka#badges?

Of course! One simply doesn't have have enough badges! Also more the the merrier 😄

babadgeka