Non conosco abbastanza Julia per sapere se è possibile applicare quanto segue alla tua situazione, ma per darti una risposta generale per situazioni comparabili: IMHO è una buona idea evitare di mantenere due codici diversi basi dello stesso pacchetto per diversi mesi.
Se la maggior parte degli utenti utilizza ancora Julia 0.6 e prevede che lo faccia per un periodo di, diciamo, di sei mesi, quindi
-
fai lo sviluppo principale anche su 0.6
-
offre una versione identica alla caratteristica per Julia 1.0, ma resiste al tuo desiderio di utilizzare qualsiasi nuova funzionalità della lingua (almeno, per il periodo di tempo che vuoi supportare 0.6).
L'obiettivo dovrebbe essere quello di avere una base di codice con > 98% di linee di codice identiche per gli ambienti entrambi . I file dovrebbero essere identici. Non mantenere due rami nel tuo sistema di controllo delle versioni, solo uno, da dove puoi costruire la versione 0.6 e 1.0 del tuo pacchetto! Potrebbe essere necessario mantenere diverse configurazioni di build per 0.6 e 1.0, ovviamente. E forse avrai bisogno di un po 'di compilazione condizionale per aggirare alcune limitazioni se non c'è assolutamente altro modo (ma dovresti cercare di mantenere piccole porzioni del codice).
Quando segui questa strada, la questione del "backporting" e della "diversa qualità del codice" semplicemente non si presentano. Basta non cadere nella trappola di credere solo perché "1.0" è ora disponibile, è necessario utilizzare immediatamente "l'ultima e la più grande" versione dell'ambiente. Se alcuni dei tuoi utenti possono o devono attendere alcuni mesi prima di passare completamente, sono sicuro che puoi farlo anche tu.
Lascia che ti parli di alcune esperienze personali. Il nostro team ha utilizzato questa strategia una volta per eseguire il porting di un programma di > 100kLOC C ++ da un vecchio framework 16 bit UI e un vecchio compilatore Borland da 16 bit ad un nuovo framework UI a 32 bit usando un nuovo compilatore MS, in un periodo di tempo di circa un anno. Non penso che avremmo potuto gestire il compito se avessimo cercato di mantenere una "versione più recente" del prodotto in una base di codice, e la più vecchia (con "funzionalità di backporting o correzioni") in una seconda base di codice.
Invece, siamo riusciti a mantenere la base di codice in uno stato in cui era possibile compilare i file di origine identici con entrambi i compilatori e gli ampli; ambienti di libreria. Abbiamo dovuto usare alcune tattiche come
-
fornisce alcuni wrapper per le vecchie API nel nuovo ambiente (come un String wrapper attorno a std::string )
-
il mirroring dei file di origine comuni in una seconda cartella utilizzando i collegamenti fisici, per separare le cartelle di compilazione, ma quando si modifica un file in una cartella, cambia automaticamente anche "l'altro file"
-
evitare l'uso di nuove funzionalità C ++ o l'uso diretto di nuove librerie (eccetto i wrapper) per il periodo di transizione.
Ovviamente, dovrai trasferire queste idee al tuo ambiente e alla tua situazione, ma spero che la strategia generale diventi chiara.