Fork me on GitHub
#clojure-dev
<
2017-06-08
>
mpenet06:06:27

True. I guess my concern is moot once proper versioning is in place. The situation was a bit unusual here (for clj) as backward compat was broken, that's why it's called an alpha I guess 🙂

dm306:06:37

to be fair - it was part of 1.9.0-alpha*

dm306:06:26

although people (me included) are treating Clojure alphas as production-ready 🙂

mpenet06:06:29

yep, we got used to it being that way. clj is one of the rare projects where you can (usually) blindly upgrade even for alphas

seancorfield07:06:40

(We have Alpha 17 in production right now and we're relying on Spec heavily)

mpenet07:06:21

Not questioning the stability, just the need to modify code to have it run with this upgrade (just greped 62 ns with clojure.spec here on a single (large) repo, not mentioning the transitive (priv) deps that also depend on spec on this same project). I guess if you don't mind spending time doing releases for each of them + updating all your ns/require declarations it's fine. If it's a mono-repo I guess it can be fine too. But with CI, build cycles, releases etc etc it ends-up costing you a lot of time. Something to be careful about for next time I guess

seancorfield13:06:14

I think it ended up being about one person day of time when Spec changed name to add alpha. It'll be less time when it switches back (that day included time spent cleaning up our use of aliases). That's a reasonable trade off for the benefits of staying on the bleeding edge. It is all "alpha" after all -- we expect occasional breakage.

seancorfield13:06:03

We unit test against master snapshot too for advanced warning of breakages.

mpenet13:06:46

1 day is a lot 🙂 but anyway, this should be a one time thing and it's the price to pay for bleeding edge