Sono imbarazzato nel dire che sono un po 'all'oscuro della procedura utilizzata per aggiornare un plugin tramite tortoise svn anche se il mio plugin è stato sul repository per anni e ha avuto oltre 300.000 download!
Non essere. SVN può essere complicato per molte persone ... quindi esaminiamo le cose passo dopo passo ...
Questo è quello che ho fatto finora.
- codifica gli aggiornamenti del plug-in sul mio locale fino a quando non sono soddisfatto
- copia su tutti i file nella cartella del mio plug-in locale in / trunk / (il plug-in e il file readme hanno numeri di versione aggiornati)
- commit della directory trunk
- fai clic con il pulsante destro del mouse sulla directory trunk e scegli crea branch / tag e impostalo per copiarlo in una cartella in / tags / con il nome come numero di versione
È corretto e nel giusto ordine? in caso contrario, qual è il modo corretto?
Quasi ...
I passaggi che dovresti seguire:
- Codifica gli aggiornamenti del plug-in localmente finché non sei soddisfatto
- Incrementa il tag "stable" nel tuo
readme.txtfile in modo che corrisponda al nuovo numero di versione
- Copia i tuoi aggiornamenti locali nella
/trunkdirectory della cartella del plugin locale
- Commettere l'intero plugin per salvare le modifiche
/trunknel repository
- Fare clic con il tasto destro del mouse
/trunke creare un nuovo tag, copiando /tags/X.X.Xdove xxx è la stessa versione nel tag "stabile" di readme.txt(passaggio 2)
- Commettere l'intero plugin per salvare il tag
per qualche motivo, sono passato dalla versione 2.8.1 alla 2.81.2 nel mio ultimo aggiornamento, questo significa che non verrà visualizzato come aggiornamento disponibile nei dashboard delle persone che hanno la versione 2.81.2 se cambio il numero della versione successiva in 2.9?
Bingo. Se hai impegnato la versione 2.81.2 come aggiornamento e le persone hanno effettivamente scaricato quell'aggiornamento, non vedranno 2.9 quando lo rilasci.
in che modo wordpress determina qual è la versione più recente e se l'utente deve aggiornare la propria versione? fa un version_compare? funziona solo con il corretto formato di versione php, no? per esempio. 2.9.2 è considerata una versione inferiore a 2.81.2? (perché, a quanto ho capito, version_compare inizia a sinistra e confronta più alto / più basso per ogni cifra, quindi 9 sarebbe considerato inferiore a 81)
Esattamente. Un confronto di versione standard di PHP vedrà la versione 2.81.2 come una versione più recente di 2.9 perché 81> 9.
Ti consiglio di rilasciare una versione 3.0 successiva, quindi fai molta attenzione durante il controllo delle versioni in futuro per evitare questo tipo di errore di battitura.
se rilevo un errore stupido nel codice che non influisce sul funzionamento del plugin, forse un errore di battitura o un'immagine aggiuntiva. Cosa modifico e mi impegno a fare in modo che eventuali nuovi download del plugin contengano la modifica?
devo modificare il trunk E la cartella dei tag e eseguire il commit di entrambi?
Se è necessario apportare una modifica minore, considerarla una versione di manutenzione . In genere seguo questo tipo di schema di versioning:
2 . 1 . 3 . 5
major minor maint build
Numeri di build che uso sempre solo internamente o per le versioni beta ... non vedrai quasi mai un numero di build da me a meno che non ti invii manualmente un file via e-mail (è come posso distribuire versioni pre-release che non interrompono gli aggiornamenti di WordPress) .
Se noto un bug in una versione live, realizzerò una patch rapida e rilascerò una versione di manutenzione. Diciamo che ho rilasciato la versione 2.2 di un plugin e qualcuno nota che ho dimenticato di invocare jQuery in modalità noConflict (). Farò una patch veloce e rilascerò immediatamente 2.2.1.
L'incremento della versione costringerà WordPress a riconoscere l'aggiornamento e fornirà la correzione a chiunque abbia già installato la versione 2.2.
Per rilasciare una versione di manutenzione, è necessario seguire esattamente gli stessi passaggi di una versione completa del sistema. Quindi apportare modifiche, incrementare la versione in readme.txt, commit /trunk, tag, ecc.
Ma una volta che hai taggato qualcosa, non lo cambi mai più. Pensa alla tua /tagscartella come congelata nel tempo. Ogni versione in quella cartella è un'istantanea del tuo plugin in un determinato momento. Non modificare mai direttamente i file nella /tagscartella.
Se ti ritrovi a pensare che potrebbe essere una buona idea, colpiscimi sulla parte posteriore della testa e rilascia una versione di manutenzione invece :-)
Come accennato da Piet, in precedenza ho scritto una buona serie di istruzioni dettagliate ... ma il sito sembra aver perso i miei screenshot. Ecco un'altra versione della stessa guida passo-passo con schermate di Tortoise ospitate sul mio sito: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/