Arrow lascia lo ZeroVer!

 ...E così siamo arrivati alla versione 1 di Arrow! Non che otto anni siano poi molti, eh. 

Arrow è uno dei pacchetti più amati e conosciuti per la gestione delle date/ore in Python. Anche adesso che la libreria standard ha fatto passi da gigante in questo settore, Arrow continua a essere una scelta raccomandabile per chi vuole sviluppare applicazioni di calendaring senza impazzire dietro alle complessità dell'algebra delle date, delle timezone e così via. Arrow è apprezzato dai nerd del calendaring come me, ma è anche, più semplicemente, un'API sensata e ragionevole per trattare problemi comuni come "aggiungi 3 settimane" o "all'ora corrispondente di New York". È un pacchetto di grande successo, con 50mila download al giorno e oltre 7000 "star" su GitHub. Viene impiegato come dependency in molte altre librerie, ed è probabilmente installato in migliaia di scenari di produzione. 

Eppure... fino a oggi non aveva mai raggiunto la versione 1.0, e quindi lo stato di "production/stable" su PyPI. 

Che cosa significa? Da un punto di vista tecnico, seguendo le regole del semantic versioning (che Python stesso adotta, più o meno), significa che Arrow d'ora in poi si impegna a non introdurre API che rompono la compatibilità con le versioni passate, a meno di non saltare con questo alla versione 2.0. Viceversa, finché un software resta nella versione "0.qualcosa", gli utenti sono avvisati che cambiamenti di API non-retrocompatibili potrebbero accadere in qualsiasi momento. 

Da un lato, mantenere il proprio software in uno stato di ZeroVer perenne aiuta la libertà di sviluppo e libera il programmatore dal peso delle promesse passate, permettendogli di cambiare l'API in modo anche radicale, senza troppi pensieri. Dall'altro, i suoi utenti saranno sempre un po' in ansia, ecco. 

Tuttavia lo ZeroVer è quasi la regola, ormai. Il modello imperante della continuous integration rende il software sempre più "malleabile", indipendente dal vecchio schema delle release. Si privilegia la rapidità di sviluppo sulla stabilità dell'API. Un contro-esempio è la libreria standard di Python, che invece continua a privilegiare la stabilità del codice anche a discapito degli aggiornamenti. Ma proprio per questo è stata notoriamente criticata come "il posto dove i moduli vanno a morire". 

Poi certo, anche nel software ZeroVer almeno un "nocciolo" di API più o meno costante, in qualche modo, viene a formarsi, almeno di fatto se non per contratto. Ma tutti abbiamo avuto almeno una volta l'esperienza di dover cambiare anche in profondità il nostro codice per adeguarci a un improvviso cambio di API delle librerie che utilizziamo. 

Alcuni dei pacchetti più famosi nell'ecosistema Python sono ancora ZeroVer, o lo sono stati per anni: Pandas (dal 2011 a gen. 2020), Flask (2010-2018), Wheel (2012-oggi), Scikit-learn (2011-oggi) e così via. Naturalmente ogni pacchetto ha la sua storia, e non è detto che per forza dietro a ogni ZeroVer ci sia uno sviluppatore che non riesce a decidersi su un'API stabile, anzi. Ma anche in questa epoca di software sempre più fluido, qualche promessa è bene metterla per scritto, ogni tanto. 

Quindi, benvenuto Arrow 1.x. D'ora in poi ti useremo con un pizzico di piacere e di sicurezza in più.