Me da vergüenza decir que no tengo ni idea del procedimiento utilizado para actualizar un complemento a través de la tortuga svn a pesar de que mi complemento ha estado en el repositorio durante años y ¡ha tenido más de 300,000 descargas!
No se SVN puede ser complicado para mucha gente ... así que repasemos las cosas paso a paso ...
Esto es lo que he estado haciendo hasta ahora.
- codificar las actualizaciones del complemento en mi local hasta que esté contento con él
- copiar todos los archivos dentro de mi carpeta de complementos local a / trunk / (el complemento y el archivo léame tienen números de versión actualizados)
- comprometer el directorio troncal
- haga clic derecho en el directorio troncal y elija crear rama / etiqueta y configúrelo para copiarlo en una carpeta en / etiquetas / con el nombre como número de versión
¿Es eso correcto y en el orden correcto? Si no, ¿cuál es la forma correcta?
Casi ...
Los pasos que debes seguir:
- Codifique las actualizaciones del complemento localmente hasta que esté satisfecho con él
- Incremente la etiqueta "estable" en su
readme.txtarchivo para que coincida con el nuevo número de versión
- Copie sus actualizaciones locales en el
/trunkdirectorio de la carpeta del complemento local
- Confirme todo el complemento para guardar los cambios
/trunken el repositorio
- Haga clic derecho
/trunky cree una nueva etiqueta, copiando /tags/X.X.Xdonde xxx es la misma versión en la etiqueta "estable" de readme.txt(paso 2)
- Confirma todo el complemento para guardar la etiqueta
por alguna razón, pasé de la versión 2.8.1 a 2.81.2 en mi última actualización, esto significa que no se mostrará como una actualización disponible en los paneles de las personas que tienen la versión 2.81.2 si cambio el siguiente número de versión a 2.9?
Bingo. Si confirmó la versión 2.81.2 como una actualización y las personas realmente descargaron esa actualización, no verán la versión 2.9 cuando la lance.
¿Cómo determina WordPress cuál es la última versión y si el usuario debe actualizar su versión? ¿hace una version_compare? que solo funciona con el formato de versión de php correcto ¿no? p.ej. 2.9.2 se considera una versión inferior a 2.81.2? (porque, según tengo entendido, version_compare comienza a la izquierda y compara mayor / menor para cada dígito, por lo que 9 se consideraría menor que 81)
Exactamente. Una comparación estándar de versiones de PHP verá que la versión 2.81.2 es una versión más nueva que la 2.9 porque 81> 9.
Le recomiendo que lance una versión 3.0 a continuación, luego tenga mucho cuidado al realizar versiones en el futuro para evitar este tipo de error tipográfico.
si veo un error tonto en el código que realmente no afecta el funcionamiento del complemento, tal vez un error tipográfico o una imagen adicional. ¿Qué edito y me comprometo a hacer que las nuevas descargas del complemento contengan el cambio?
¿Tengo que editar el tronco Y la carpeta de etiquetas y confirmar ambos?
Si necesita hacer un cambio menor, considérelo una versión de mantenimiento . Normalmente sigo este tipo de esquema de versiones:
2 . 1 . 3 . 5
major minor maint build
Números de compilación que solo uso internamente o para versiones beta ... casi nunca verás un número de compilación de mí a menos que te envíe un archivo manualmente por correo electrónico (así es como puedo distribuir versiones preliminares que no rompan las actualizaciones de WordPress) .
Si noto un error en una versión en vivo, haré un parche rápido y lanzaré una versión de mantenimiento. Digamos que lancé la versión 2.2 de un complemento y alguien nota que olvidé invocar jQuery en modo noConflict (). Haré un parche rápido e inmediatamente lanzaré 2.2.1.
El incremento en la versión obligará a WordPress a reconocer la actualización y proporcionará la solución a cualquiera que ya haya instalado la versión 2.2.
Para lanzar una versión de mantenimiento, debe seguir exactamente los mismos pasos que si lanzara una versión completa del sistema. Realice cambios, incremente la versión readme.txt, confirme /trunk, etiquete, etc.
Pero una vez que ha etiquetado algo, nunca lo cambia de nuevo. Piensa en tu /tagscarpeta como congelada en el tiempo. Cada versión de esa carpeta es una instantánea de su complemento en un momento específico. Usted debe no cambiar los archivos de la /tagscarpeta directamente.
Si crees que podría ser una buena idea, golpéate en la parte posterior de la cabeza y lanza una versión de mantenimiento en su lugar :-)
Como mencionó Piet, escribí un buen conjunto de instrucciones paso a paso anteriormente ... pero el sitio parece haber perdido mis capturas de pantalla. Aquí hay otra versión de la misma guía paso a paso con capturas de pantalla de Tortoise alojada en mi propio sitio: http://eamann.com/tech/how-to-publish-a-wordpress-plugin-subversion/