😯

Mi sembra un'ottima decisione

baahh

cioe', ok per la decisione, ma quante ore spese a parlarne per niente

bene, immagino datomic opensource sia il passo successivo 🙂

Non ci conterei troppo 🙂

mi trovo molto d'accordo con la decisione di splittare spec in una contrib lib

essendo una dipendenza di clojure per gli utenti non c'e` virtualmente alcuna differenza e permette iterazioni piu` veloci

sarebbe interessante se core.async stesso diventasse un'altra dipendenza bundlata con clojure come core.spec

@bronsa ah quindi includendo 1.9 me la becco comunque ma come dipendenza... mmmmh quindi e' finita l'era del mi scarico lo zip ed apro un repl?

si` e` una dipendenza transitiva di 1.9 e lo sara` per sempre

l'idea AFAICT e` di tenere spec come parte del bundle core ma semplicemente rilasciarla come un artifact separato per poter separare i development cycles

mmmh, rileggo l'ANN

Mmmh, Alex parla di rimuovere completamente i spec-ns da core, quindi non sembra che i sorgenti di spec saranno nel jar di clojure

no, non saranno nel jar di clojure

beh se questa "porta" si apre, ci possiamo liberare anche dei sorgenti di ASM

ma essendo spec una dipendenza di clojure, verra` inclusa in qualsiasi progetto dipenda da clojure

assumo rilasceranno anche una versione in cui spec e` bundlata per l'use case che menzionavi prima

mmmhhh...

(l'uberjar diciamo)

>beh se questa "porta" si apre, ci possiamo liberare anche dei sorgenti di ASM

penso fosse esattamente questa l'idea

iniziare a modularizzare clojure

vabbe' speriamo che vada tutto bene... 🙂