Sto forking un pacchetto python, dove mi aspetto che l'autore del pacchetto unisca le mie modifiche nel prossimo futuro. L'autore del pacchetto non viene rilasciato molto spesso, quindi mi aspetto di avere il mio fork temporaneo come dipendenza per alcuni dei miei altri pacchetti. Devo creare un numero di versione appropriato per la mia forcella conforme a pip/setuptools.Qual è un buon numero di versione di pip/setuptools per un fork di un pacchetto?
Supponiamo che la versione corrente sia 1.6.4 e che la prossima versione dell'autore sia 1.6.5. Una versione appropriata per la forcella sarebbe 1.6.4.1 o 1.6.5.dev20140520? Entrambi sembrano essere compatibili con PEP440, ma ho anche avuto esperienza con le versioni recenti di pip non trovando le versioni dev a meno che non si utilizzi in modo specifico il flag pre. Sembra che 1.6.4.1 sia una buona scelta, ma non so quanto sia felice pip con un formato N.N.N.N (ad esempio, lo pip lo considererà una versione pre?).
C'è qualche convenzione standard per questo? Nota, non voglio cambiare il nome del pacchetto dell'autore, ma ho bisogno di un fork temporaneo che i miei altri pacchetti possano installare con problemi minimi.
Non c'è uno standard. In effetti, devo ancora vedere un buon schema di versioning (e un ordine parziale sui numeri di versione) per i pacchetti che potrebbero fork; 1.6.4-yourname-1.0 è usato dai packager Linux. –
Questa è la convenzione che uso da anni in una situazione del genere. Tuttavia, il problema è che i programmi di installazione dei pacchetti python non riconoscono N.N.N-fork-N come una convenzione di denominazione valida, quindi sto cercando qualcos'altro. –
Il pip non gestisce gli URL di controllo versione in 'requirements.txt'? –