Sto scrivendo uno strumento Python per convertire / archiviare i dati da un plaintext file format per i dati volumetrici generati dai calcoli di chimica computazionale nel binario HDF5 formato utilizzando h5py . I file di testo in chiaro sono spesso enormi , spesso 100 MB o più e, nei casi in cui alcuni tipi di compressione semi-lossy sono accettabili, filtro pipeline integrato in HDF5 / h5py consente di archiviare con un fattore di compressione compreso tra 50 e 300x (benchmark qui , per i curiosi). Quindi, mentre lo scambio di file non compressi è terribilmente scomodo, se non del tutto impraticabile, la mia speranza è che questi nuovi file compressi diventino alla fine la lingua franca del mezzo.
Un ulteriore vantaggio del formato HDF5 è che è multipiattaforma e leggibile da qualsiasi applicazione che possa collegarsi al suo Interfacce C / C ++ / FORTRAN o che supporta gli script Python (tramite h5py ). Pertanto, spero anche che varie applicazioni software che attualmente supportano la lettura / scrittura del formato di file in chiaro finiranno per implementare il supporto per questo aroma HDF5.
Ad un livello elevato, HDF5 memorizza i dati in coppie chiave / valore. Nel mio strumento Python, ho definito le chiavi standard per i vari valori di dati che sto usando al momento. Tuttavia, prevedo che il set di chiavi utilizzate nei file HDF5 cambierà nel tempo. Dato che (1) la struttura del formato del file probabilmente cambierà e che (2) il mio obiettivo è che altri software interagiscano direttamente con questi file, ho iniziato a mettere insieme un specifiche file indipendenti e con versione per il formato.
Dove sono un po 'confuso è la decisione sul paradigma di versioning per questa specifica di file. Sono completamente a bordo del treno SemVer per il codice (o almeno la mia comprensione di questo: {API breaking change}.{API extending change}.{bugfix} ). Ma, non posso decidere se questo paradigma ha senso per il controllo delle versioni di una specifica file.
Da un lato, mi piace l'approccio di avere un solo numero di versione. Ogni versione sarebbe la sua entità autonoma, e indipendentemente da quanto simile sia una versione data ad un'altra sarebbe nettamente distinta. Inoltre, non importa molto se la specifica cambia in un modo "non lineare" (ad esempio, v3 e v6 sono compatibili con alcune metriche, ma v3 / v4 e v3 / v5 non lo sono) perché la compatibilità tra versioni per un dato l'applicazione dovrebbe (probabilmente?) essere sempre un insieme di mapping uno-a-uno.
D'altra parte, in situazioni in cui, per esempio, l'unica modifica nel passaggio dalla versione x alla versione x+1 è l'aggiunta di una nuova chiave, allora ci sarebbe un certo valore in una struttura tipo SemVer, dì un formato X.Y , perché quindi un'applicazione potrebbe definire intervalli di compatibilità (ad esempio >=2.3,<3.0 , come con i pacchetti Python). Tuttavia, i "salti" non lineari nelle specifiche tendono a portare comunque ad un rapido incremento della "versione maggiore", diminuendo il valore della specifica di compatibilità range-wise.
Quindi, la domanda per il titolo: È appropriato usare il Versioning semantico per le specifiche per un formato di file chiave / valore? Perché o perché no?