Fork me on GitHub

I'm considering adopting this version scheme for bb: 22.9.169: year.month.release-count We already have the release-count. I think it makes sense to drop the 0.whatever prefix and move to date versioning instead.

👍 7

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

😞 2

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?

💯 1

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

👍 1

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




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 😛

Dimitar Uzunov10:09:34

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

👍 1

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

Daniel Jomphe11:09:42

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

👍 1

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 ;)

🙌 1

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:

So date + release number separated by hyphen


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


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.

Steffen Glückselig10:09:44

Looking for a pattern for piping with babashka.cli Since exposing functions on the command line became such a breeze with babashka.cli, I was thinking about how to chain these functions together. So instead of providing orchestrating functions for reasonable combinations of "functional" functions I'd like to expose these individual functions directly at the CLI and pipe their outputs. E.g. I'd retrieve a list of IDs in one function and pipe these IDs to another function that processes that list. bb -o -x api/get-current-ids --token <TOKEN> | bb -io -x api/delete-by-ids --token <TOKEN> I'd also like to be able to call delete-by-ids directly, though: bb -io -x api/delete-by-ids --token <TOKEN> --ids 1001, 1002, 1205 On another note: Reading through some of the threads about piping here, I came to realize that I'd have to use something like (line-seq (.BufferedReader. *in*)) in order for piping to work on windows.

Steffen Glückselig12:09:14

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
                                (println "piping!")
                                (line-seq ( *in*))))]
which uses
(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."
  (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]))
and is used like
(with-cli-pipe-for :workitem-ids
  (defn test1 [{:keys [workitem-ids] :as m}]
    (prn m)
    (run! println workitem-ids)))
I.e. a function that should be used in a pipe is wrapped with the macro and the CLI-param that will accept the piped values. Testing it:
(with-open [is ( "1\n2\n3\n5")]
  (binding [*in* is]
    (test1 {:opt1 true})))


Lookey! If your library works as a babashka dependency you too can show this badge! 🎉

babashka 5

@U7ERLH6JX inspired by your bb compatible badge, did you notice I created a bb built-in


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

nbb 1
babashka 1
simple_smile 1


simple_smile 1