Come gestire le richieste pull al repository originale con modifiche dipendenti da una versione più recente del compilatore

2

Ho un progetto github che ho biforcato. Il repository originale è stato scritto per una versione di OCaml prima della versione 4.02.1. Il compilatore 4.02.1 mi dà vari avvisi di deprecazione che ho intenzione di risolvere e impegnare al mio repo. Non sono sicuro di dover trasferire le mie modifiche al progetto originale.

La mia domanda è: in una situazione in cui il codice di una terza parte (me) richiede una versione più recente di una libreria o compilatore rispetto all'uso dell'autore / progetto originale, come dovrei gestire la condivisione del mio codice con il repository originale? Sembra sconsiderato offrire semplicemente il nuovo codice senza alcun tipo di spiegazione e certamente non voglio rompere la build sul repository originale.

Come viene gestito questo tipo di situazione?

    
posta Green 16.06.2015 - 19:28
fonte

2 risposte

2

Descriverò come viene tipicamente gestito in github. Tuttavia tutto ciò è solo codice, quindi è pertinente altrove.

Progetti davvero spiffy come quelli che ho corso, hanno dei test per assicurarsi che tutto funzioni correttamente.

Inoltre, i progetti interessanti come quelli con cui lavoro hanno una sorta di integrazione continua . Questo significa che esiste un modo per alcuni sistemi esterni indipendenti di eseguire i test da solo. github organizza un progetto per utilizzare un set predefinito di git commit hook che dirà al sistema indipendente che è stata effettuata una modifica.

Di solito ci sono istruzioni che puoi fornire al sistema di integrazione continua che aiuta a costruire il sistema. Nello specifico queste istruzioni o configurazione potrebbero specificare quale versione (o versioni) di OCaml testare con.

Con tutto questo a posto, quando si invia una "richiesta pull", github esegue il hook git che dà il via al continuo sistema di integrazione che rende disponibile lo stato del controllo. Github lo noterà (perché il gancio è stato inscatolato e personalizzato per un ci, quindi sa dove guardare). E quindi avviserà il potenziale proprietario se è sicuro unire il codice o meno. Anche senza integrazione continua github eseguirà una fusione laterale per assicurarsi che non vi siano conflitti di fusione.

Ok. Ma supponiamo che tu stia lavorando con progetti meno sofisticati. Dato che questo è git, anche questo è bello, può aiutarti da solo.

Qui quello che potresti fare è creare un ramo e limitare le modifiche a quel ramo. Quindi richiedi un tiro da quel ramo. Il proprietario probabilmente unirà le modifiche in un ramo con lo stesso nome e poi lo proverà. Se le cose funzionano, allora quella persona unirà il ramo nel ramo "principale".

E infatti se stai usando github e le cose fantasiose o no, è sempre bene lavorare in un ramo per le tue modifiche fuori da un altro progetto. Vedi anche git flow

    
risposta data 17.06.2015 - 05:49
fonte
1

In realtà non è diverso da qualsiasi altro cambiamento. Se si tratta di una quantità significativa di lavoro, eseguirlo prima dalla mailing list. Qualcuno potrebbe già lavorarci sopra. Se è una quantità insignificante di lavoro, fallo e invia una richiesta di pull con una spiegazione chiara. Il peggio che accadrà sarà respinto.

La deprecazione viene eseguita per diversi motivi e spesso le tue modifiche possono essere rese compatibili con le versioni precedenti di versioni precedenti. Prova a farlo se puoi. Ad esempio, i caratteri ISO-latin1 negli identificatori sono stati aggiunti agli avvisi di deprecazione in 4.02. Puoi certamente compilare identificatori senza caratteri ISO-latin1 nelle versioni precedenti.

    
risposta data 16.06.2015 - 23:41
fonte

Leggi altre domande sui tag