Forked un progetto, da dove iniziano i miei numeri di versione?

12

Ho biforcuto un progetto e ne ho cambiato molto. Questo fork non è solo un piccolo cambiamento di funzionalità qui e una correzione di bug sepolti lì, è un cambiamento piuttosto sostanziale. Solo la maggior parte del codice principale è condivisa.

Ho modificato questo progetto alla v2.5.0. Per un po 'ho iniziato a versionare il mio fork alla v3.0. Tuttavia non sono sicuro che questo sia il modo giusto, principalmente perché quando quel progetto arriva alla v3.0, le cose diventano confuse. Ma non voglio ricominciare da v1.0 o v0.1 perché ciò implica infanzia, instabilità e non-rigidità di un progetto. Questo non è vero, poiché la maggior parte del codice di base è molto raffinata e stabile.

Sono davvero perso su cosa fare, quindi chiedo qui: qual è il modo standard di affrontare questo tipo di situazione? La maggior parte delle forcelle ricomincia da capo, aumenta i numeri di versione o fa qualcos'altro di cui non sono a conoscenza.

versioning

— TheLQ
fonte

5

Non vedo come 1.0 implichi l'infanzia o l'instabilità. Qualunque cosa al di sotto di 1.0 sì, ma 1.0 implica che è fuori dal periodo di "infanzia" e pronto per il rock. Se ti fa

— sentire

1

Per curiosità, cosa hai rovesciato?

— compman,

13

La maggior parte delle forcelle che ho visto ricominciare dalla versione 1.0. Ma suppongo che tu abbia anche cambiato il nome del tuo fork, quindi non sono sicuro del motivo per cui ci sarebbe confusione se avessi semplicemente iniziato dalla v3.0.

Quello che vorrei fare è cambiare il nome del progetto, rilasciare la versione 1.0 e chiarire che il progetto è un fork di un altro progetto. Non penso che ci sarà confusione con questo approccio.

Se sei davvero preoccupato per l'etichetta "1.0", rilascia la versione 2.0 poco dopo 1.0 ...

— Dean Harding
fonte

... o rilasciare direttamente v2.0, saltando del tutto v1.0. Non sarebbe la prima volta che questo viene fatto.

— Konamiman,

Nella mia azienda un progetto è iniziato anche alla v2.4.

— user253751

6

Avere la propria tabella di marcia e attenersi ad essa, a partire dal numero della versione originale ma non provare a gareggiare con la versione corrente del prodotto originale.

— dukeofgaming
fonte

1

Se non stai cercando di mettere in parallelo il progetto originale in qualche modo, non ci sarà alcuna correlazione significativa tra i numeri di versione in futuro. Ciò significa che non ha senso tentare di stabilire una simile correlazione ora - a partire da 3.0 - perché stabilirà solo un'aspettativa insoddisfacente.

— Tom Anderson,

Sono corretto. Dovresti iniziare la tua v1.0, che ti aiuterà a distinguere. Le versioni dovrebbero significare qualcosa, non solo qualche acrobazia di marketing (v.gr. "v5.4" solo per non sembrare nuovo).

— dukeofgaming,

1

@TomAnderson: Se si avvia alla versione 2.5, per esempio, e realizza la prima versione del suo fork 2.6 o 3.0, può indicare l'altra app come la storia completa del suo progetto. Quale è una correlazione modestamente significativa.

— DougM,

3

Potresti voler considerare se (e quanto) il tuo progetto sarà correlato con quello originale. Se prevedi di eseguire il porting di nuove funzionalità dal progetto originale nel tuo, potresti considerare di mantenere i numeri di versione corrispondenti alle versioni dell'originale.

Ad esempio, controlla MariaDB, che è un fork di MySQL. Vogliono mantenerlo un sostituto 'drop-in' per MySQL, quindi ad esempio MariaDB 5.2 ha tutte le caratteristiche di MySQL 5.2.

Vedi: http://kb.askmonty.org/v/mariadb-versus-mysql

Nota: da quando è stata pubblicata questa risposta, MariaDB si è sostanzialmente discostata da MySQL e ora sta seguendo il proprio schema di versione.

— Mchl
fonte

1

0.1 può indicare l'infanzia, ma verion 1.0+ significa stabile. Un aumento dei principali numeri di versione, ad es. 2.0, 3.0, indicava generalmente un grande cambio di funzionalità.

Per esempio

La versione 1.0 della mia applicazione era uno strumento per l'esecuzione di script di test con installazione,
La versione 2.0 ha rimosso la differenziazione tra script di test e script di installazione dell'ambiente,
La versione 3.0 ha aggiunto una GUI per la scrittura di script come diagrammi di flusso. Sono prodotti riconoscibilmente diversi, ma anche la versione 1 era un prodotto funzionante, completamente stabile, ecc. Le versioni 2 e 3 sono nate perché si è deciso che questi grandi cambiamenti sarebbero stati positivi. Se non avessimo voluto questi grandi cambiamenti e avessimo appena continuato a correggere errori, ecc. I numeri di versione minori sarebbero appena aumentati, 1.10,1.20 ecc., E ciò sarebbe andato bene.

Quello che sto dicendo è che i numeri di versione principali non indicano la maturità, indicano i set di funzionalità principali. Questo è stato un po 'tangente da come numerare la versione del tuo prodotto.

Quello che ho visto prima, che mi è piaciuto molto, è stato ricominciare il controllo delle versioni da 1.0 (o da 3.0 se preferisci davvero) e poi tra parentesi che dicevano da quale versione dell'originale sono state estratte le funzionalità.

Inizialmente: " MyFork v1.1 (basato su OrigProg v3.0)
Alcuni improvvisatori realizzati su MyFork: MyFork v1.3 (basato su OrigProg v3.0)
OrigProg ha rilasciato una versione principale e MyFork ha estratto e unito: MyFork v2.1 (basato su OrigProg v4.0)
Ho apportato alcune importanti modifiche a MyFork (probabilmente non sarà mai più possibile unire facilmente OrigProg): MyFork v3.0 (basato su OrigProg v4.0)

— Lyndon White
fonte

0

Se possibile, unisci nuovamente la forcella al progetto originale. Non posso sottolineare abbastanza.

Rigenera i tuoi numeri di versione, quindi usa quello da cui hai biforcato più un suffisso di data.

2

Passando da "Python 1.1" a "Userthon 1.1. {DATA}" si rompe il formato previsto dei numeri di serie.

— DougM,