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

La maggior parte delle forcelle che ho visto ricomincia dalla versione 1.0. Ma suppongo che tu abbia anche cambiato il nome della tua forchetta, 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 credo che ci sarà alcuna confusione con questo approccio.

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

Avere la propria roadmap e attenersi ad essa, iniziando dal numero della versione originale, ma non cercare di competere con la versione corrente del prodotto originale.

Potresti considerare se (e quanto) il tuo progetto sarà correlato con quello originale. Se hai intenzione di trasferire nuove funzionalità dal progetto originale al tuo, potresti considerare di mantenere i numeri di versione corrispondenti alle versioni dell'originale.

Come esempio, controlla MariaDB, che è un fork di MySQL. Vogliono tenerlo un sostituto "drop-in" per MySQL, quindi per esempio MariaDB 5.2 ha tutte le funzionalità di MySQL 5.2.

Vedi: link

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

0,1 può indicare l'infanzia, ma verion 1.0+ significa stabile. Un aumento dei numeri di versione principali, ad esempio 2.0, 3.0, indica generalmente un cambiamento di funzionalità di grandi dimensioni.

Ad esempio

• La versione 1.0 della mia applicazione era uno strumento per eseguire script di test con l'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 continuato a fare correzioni di bug, ecc. I numeri di versione minori sarebbero aumentati di 1.10,1.20, ecc. E sarebbe andato bene.

Quello che sto dicendo è che i numeri di versione principali non indicano la maturità, indicano i principali set di funzionalità. Questo è stato un po 'tangibile rispetto al numero di versione del tuo prodotto.

Quello che ho visto prima, che mi è piaciuto calmo era avvia nuovamente il versioning da 1.0 (o da 3.0 se lo preferisci) e poi tra parentesi che dicono da quale versione dell'originale sono state estratte le caratteristiche.

• Inizialmente: " MyFork v1.1 (basato su OrigProg v3.0)
• Alcune improvenet apportate a MyFork: MyFork v1.3 (basato su OrigProg v3.0)
• OrigProg ha rilasciato una versione principale e MyFork ha tirato e unito: MyFork v2.1 (basato su OrigProg v4.0)
• Apportate alcune modifiche importanti a MyFork (probabilmente non sarà più possibile fondersi facilmente con OrigProg): MyFork v3.0 (basato su OrigProg v4.0)

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

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