dipendenze del pacchetto hackage e le librerie a prova di futuro

Question

Nella sezione dipendenze di un file cabala:

Build-Depends: base >= 3 && < 5, transformers >= 0.2.0 

dovrei fare qualcosa di simile

Build-Depends: base >= 3 && < 5, transformers >= 0.2.0 && < 0.3.0 

(mettendo limiti superiori sulle versioni dei pacchetti dipendo on)

oppure no?

userò un esempio reale: il mio pacchetto "List" sulla Hackage (trasformatore Lista monade e la classe)

• Se non metto il limite - il mio pacchetto potrebbe rompersi da un cambiamento nella " transformers"
• Se faccio mettere il limite - un utente che utilizza dei 'transformers', ma utilizza una nuova versione di esso non sarà in grado di utilizzare lift e liftIO con ListT perché è solo un esempio di queste classi di trasformatori-0,2 .x

Immagino che le applicazioni debbano sempre mettere limiti superiori in modo che non si rompano mai, quindi questa domanda riguarda solo le librerie:

Devo usare il limite di versione superiore sulle dipendenze o no?

Answer 1

C'è un esplicito policy che consiglia i limiti superiori: vedere in particolare la sezione 3 ("Dipendenze in Cabal"). Le altre risposte danno qualche ulteriore giustificazione per questa politica.

In breve - il limite superiore deve essere in forma di < A.(B+1) dove A e B sono i primi elementi della versione corrente (A.B.C...). Questo perché aumentare A.B dovrebbe significare che la versione interrompe le vecchie API.

Answer 2

L'IMO che applica i limiti superiori ai numeri di versione accettati è la cosa giusta da fare. Data la semantica dei numeri di versione utilizzati da Hackage, non vi è sicuramente alcuna garanzia che il pacchetto funzioni con, in questo caso, i trasformatori 0.3.0.

Non ho visto alcuna discussione vera su questo però e non sembra esserci una raccomandazione generale per usare i limiti superiori tranne per il pacchetto base.

Answer 3

Pensate alle modalità di guasto:

• Con il limite superiore, sia il pacchetto costruisce o cabala bela su una dipendenza di compilazione insoddisfatto. La colpa è chiaramente assegnata.

• Senza il limite superiore, il cliente ha una versione recente di trasformatori e non è retrocompatibile. Il tuo software non riesce a costruire; GHC bleats su come il tuo codice non viene compilato. Il tuo software sembra scadente.

Inserire il limite superiore.