Come eseguire la versione di un progetto con dipendenze e origini dati

Question

Come eseguire la versione di un progetto con dipendenze e origini dati

#1 da (3 voti)

4

Le mie scuse se la mia domanda non sarà chiara in quanto non ho esperienza nel campo del versioning di prodotti / progetti. E a partire: ho un progetto che ha più librerie e dipendenze di fonti di dati e ogni libreria dipende da un'altra libreria o fonte di dati. Ad esempio:

   <-- L1 <-- L2 <-- DS1
P1                    |
   <--------- L3 <----|

Dove P1 è il progetto, L1-3 è librerie e DS1 è un'origine dati. DS1 non ha funzionalità, semplicemente aggiungendo o rimuovendo dati da esso. L'output finale del progetto P1 è una tabella di dati. In un punto di vista il progetto non è un software ma i dati.

Quello che voglio è usare un "sistema di controllo delle versioni" che incorpori le modifiche in ogni libreria o fonte di dati.

E qui ci sono i miei pensieri.Inizialmente ho pensato a quanto segue:

P1 avrà un alpha , versione beta 'beta' (che dipende sempre dalle versioni di librerie e origini dati).
avranno un semantico simile al versioning e
fonti di dati solo un numero incrementale (ecc 1,2,3 ecc.)

E questo sarebbe stato rilasciato internamente come:

 --------------------------------------
|project Ver|  L1  |  L2  |  L3  | DS1 |
|--------------------------------------|
|   A       |  1.0 |  1.1 |  1.3 | 1   |
|   B       |  1.2 |  1.2 |  1.4 | 1   |
|   C       |  1.4 |  1.3 |  1.5 | 1   |
|   D       |  1.5 |  1.5 |  2.8 | 2   |
                   .
                   .
                   .

Ma come ho detto prima alcune librerie sono dipendenti da alcune altre librerie o origini dati e queste informazioni non sono in quella tabella. Come può incorporarlo?

Se un'origine dati modifica la versione (modifica dei dati) se la versione dipendente cambia o rimane invariata?

Genneralmente, come si potrebbe ignorare questo problema? Qualsiasi informazione è utile.

versioning semantic-versioning

posta Mpizos Dimitris 22.02.2017 - 16:15

fonte

1 risposta

Leggi altre domande sui tag versioning semantic-versioning

Come documentare l'API REST prima della codifica Come creare un simulatore per algoritmi distribuiti scritti in un linguaggio semplice

score 3 · Answer 1

Poiché il vero obiettivo del progetto è la tabella dei dati di output , sono propenso ad aggiungere un altro numero di versione per l'output stesso. Chiamiamo OUTPUT .

Quindi ora abbiamo tutte queste versioni in versione:

+--------+-------+-------+-------+-------+-----+
| OUTPUT |  P1   |  L1   |  L2   |  L3   | DS1 |
+--------+-------+-------+-------+-------+-----+

Dove

OUTPUT è l'output della tabella di dati
P1 è il programma principale
L1 - L3 sono librerie
DS1 è l'origine dati

Il versioning semantico dovrebbe essere di grande aiuto. Puoi "bollare" i cambiamenti di compatibilità (cambiamenti di versione "principali" nella terminologia semantica) in cui l'output o le dipendenze potrebbero essere influenzati.

Come hai già concluso, il versioning semantico è inutile per l'origine dati ( DT1 ), poiché le modifiche tutte sono "modifiche di compatibilità" in termini di output.

Ecco come potrebbe essere la tua (sorprendentemente veloce) cronologia del progetto:

+-----+--------+-------+-------+-------+-------+-----+
|     | OUTPUT |  P1   |  L1   |  L2   |  L3   | DS1 |
+-----+--------+-------+-------+-------+-------+-----+
| Sun |      1 | 1.0.0 | 1.0.0 | 1.0.0 | 1.0.0 |   1 |
| Mon |      1 | 1.0.1 | 1.0.0 | 1.0.0 | 1.0.0 |   1 |
| Tue |      1 | 1.0.1 | 1.3.0 | 1.0.0 | 1.0.0 |   1 |
| Wed |      1 | 1.1.0 | 2.0.0 | 1.0.0 | 1.0.0 |   1 |
| Thu |      2 | 1.1.0 | 2.0.0 | 1.0.0 | 1.0.0 |   2 |
| Fri |      3 | 2.0.0 | 2.0.0 | 1.0.0 | 1.0.0 |   2 |
| Sat |      3 | 2.0.0 | 2.0.0 | 1.1.0 | 2.0.0 |   2 |
+-----+--------+-------+-------+-------+-------+-----+

Domenica, hai avviato il progetto e tutte le versioni sono a 1 o 1.0.0.
Lunedì, il progetto principale P1 ottiene una correzione di bug e la versione è aggiornata a 1.0.1 . Non sono necessarie altre modifiche alla versione. Hai confermato a livello di codice che questa correzione non ha influenzato OUTPUT .
Martedì, la libreria L1 ottiene una piccola modifica. Non è una modifica di compatibilità, quindi la versione di P1 e OUTPUT non avrà bisogno di modifiche.
Mercoledì, la libreria L1 ottiene un cambiamento importante. Per questo motivo, anche il tuo progetto principale P1 deve essere modificato. Tuttavia, hai confermato a livello di codice che OUTPUT non è stato modificato, quindi la sua versione non cambia.
Giovedì è stata aggiornata l'origine dati DS1 . Ora cambierà anche la versione di OUTPUT .
Venerdì l'applicazione principale P1 ha subito una modifica importante, che riguarda anche OUTPUT .
Sabato, la libreria L1 ha un grande cambiamento. La libreria L2 dipende dalla libreria L1 , quindi ottiene una piccola modifica. Nient'altro è interessato da questo cambiamento.

Credo che per farlo correttamente occorrerà una grande disciplina. Consiglierei di mantenere un tavolo molto simile a questo (con date effettive che sostituiscono i giorni della settimana, ovviamente) insieme a note molto chiare sulle dipendenze - specialmente le dipendenze tra biblioteche!

Ogni cambiamento dovrebbe essere esaminato attentamente per gli effetti collaterali che "esplodono" attraverso il grafico delle dipendenze. Avere un tavolo dovrebbe essere di grande aiuto in questo.

Qualsiasi cambiamento di compatibilità che interessa una dipendenza deve aggiornare il numero di versione principale di questo schema per avere una speranza di funzionamento. Una libreria potrebbe arrivare fino alla versione 102.0.0. Va bene, ci sono un sacco di numeri. : -)