¿Cuál es la importancia de escribir un complemento compatible con <WP 3.x hoy en día?

Actualmente estoy escribiendo un complemento simple con publicaciones personalizadas y un par de funciones, usando metadatos de publicación y agregando un par de variables a la tabla de "opciones" en la base de datos. Durante mi investigación, vi algunas referencias en el WP Codex sobre hacer que el complemento sea compatible con versiones anteriores a WP 3.xy me preguntaba qué tan importante es ahora incorporar esa compatibilidad.

Por ejemplo, la versión más antigua de WP que vi instalada (por un cliente) fue 3.2, o en algún lugar por allí. No puedo imaginar que muchas personas tengan algo mayor que 3.x, pero podría estar equivocado. Sé que, en teoría, siempre debe intentar que sea perfectamente compatible, pero, de manera realista, ¿alguien sabe lo importante que es incluir esa capacidad?

Gracias

Siempre escriba complementos para la versión actual y tenga en cuenta las compilaciones nocturnas de las próximas versiones. Cualquier otra cosa no importa.

Editar como @toscho señaló en un comentario:

Puede haber alguna explicación necesaria de por qué es así.

1. Porque yo lo digo.
2. Los complementos solo necesitan ser compatibles con core porque si todos juegan con las reglas, nada fallará. Si un complemento no juega con las reglas, entonces tiene un error . Y ese error necesita reparación y no otra cosa y no otro plugin o tema.
3. Los usuarios que no actualizan WordPress son el resultado de complementos defectuosos que se utilizan y no pueden abandonarse en los sistemas sin mucho trabajo. Como está escrito en (2), son errores de los que no tiene que preocuparse. Los errores deben corregirse, no su complemento considerando el código de terceros roto.
4. Legacy Code no necesita soporte. Necesita reemplazo. No es tu problema.
5. Las cosas cambian a gran escala en las principales versiones XX. Cuando intenta admitir versiones anteriores, a menudo necesita soluciones alternativas diferentes y mucha comprobación de versiones. Es decir (a) una pesadilla de mantenimiento (b) aumenta la base del código (c) hace que las pruebas unitarias sean imposibles ya que tienen que ejecutarse en una versión, no menos, no más y finalmente (d) disminuyen el espacio en disco y el rendimiento del servidor (en mayoria de los casos).
6. WordPress ya tiene una base de código muy antigua que carece de mejoras en muchos bordes y esquinas. En resumen: WordPress es antiguo, utiliza una versión de PHP que ya no es compatible como mínimo y, por lo tanto, ya es compatible con versiones anteriores en niveles mucho más bajos que en la API pública de su aplicación.

Ahora ve y pregúntate:

Cuando ya admite una versión de PHP que ya no es compatible, ¿por qué querría admitir una aplicación que ni siquiera es compatible con sus creadores?

Recuerde que el lanzamiento de WordPress 3.0 requiere PHP5. En ese momento, muchas empresas de alojamiento aún no ejecutaban PHP5 en sus servidores. Así que hubo un período de tiempo en que algunos sitios de WordPress NO PODRÍAN actualizarse a WordPress 3.0 porque sus compañías de hosting no mantenían sus servidores actualizados.

Han pasado muchos años (3+) desde el lanzamiento de WordPress 3.0, por lo que ser compatible con WordPress <3.x no es un complemento muy común.

La mayoría de las instalaciones de WordPress están desactualizadas . Actualmente, solo el 5.2% de todas las instalaciones se ejecutan en la última versión 3.6.
El 27.3% todavía está en la versión 3.0.

Puede pensar que debe admitir estas versiones antiguas con código compatible. Pero piense en las implicaciones:

• Tienes que probar todas las versiones oficialmente compatibles.
• Debe manejar API incompatibles como el cargador de medios, que cambió drásticamente en 3.5.
• Hace que sus usuarios piensen que está bien no actualizar WordPress, porque aún funciona.
• Necesita más código, más pruebas y más tiempo para que el soporte haga lo mismo.

Y los usuarios de estos probablemente ni siquiera instalarán su complemento porque saben que los nuevos complementos rompen su sitio. En términos de alcance de mercado, puede ganar un poco con un código compatible con versiones anteriores. En términos de eficiencia, pierdes.

Mi regla general para los complementos que escribo es la compatibilidad con la versión actual menos 1, por lo que todos los complementos que escribiría serían compatibles con 3.6.xy 3.5.x. Si bien un complemento en particular puede funcionar en versiones anteriores, no lo garantizo ni lo apoyo si tiene problemas.

Hace cuatro meses, me hice cargo del mantenimiento de un complemento popular. Antes de comenzar a trabajar en él, el complemento no había tenido una actualización en 2 años. Hice un montón de correcciones de errores, lancé la nueva versión, y 2 días después escuché de un tipo que dijo que la nueva versión causó la pantalla blanca de la muerte en su sitio. Después de investigarlo, todavía estaba ejecutando WordPress 2.9.2, y mi actualización usó la función home_url, introducida en 3.0. No tengo idea de por qué el chico decidió actualizar este complemento de inmediato, a pesar de que no había actualizado su instalación de WordPress en 3 años. Cuando hice la nueva versión, nunca pensé en probar WordPress 2.9.2.

Aquí está la moraleja de la historia: en el archivo readme.txt de su complemento , hay un número de versión "Requiere al menos" en el encabezado. Úsalo. A medida que realiza actualizaciones, si no tiene ganas de probar versiones antiguas, increméntelas. Eso desalentará a los usuarios que se niegan a actualizar sus instalaciones de WordPress de actualizar su complemento.

Actualmente estoy escribiendo un nuevo complemento relacionado, y planeo hacerlo solo en WordPress 3.6, porque quiero usar la biblioteca getid3 incluida en el núcleo. No deseo lanzar un nuevo complemento para una versión central antigua.