Qual é a importância de escrever um plugin compatível com <WP 3.x hoje em dia?

Atualmente, estou escrevendo um plugin simples com postagens personalizadas e algumas funções, usando metadados de postagem e adicionando algumas variáveis ​​à tabela "opções" no banco de dados. Durante minha pesquisa, vi algumas referências no WP Codex sobre como tornar o plug-in compatível com versões anteriores ao WP 3.x e eu estava imaginando o quão importante é agora incorporar essa compatibilidade.

Por exemplo, a versão mais antiga do WP que eu já vi instalada (por um cliente) era 3.2 ou em algum lugar por aí. Não consigo imaginar muitas pessoas com algo acima de 3.x, mas posso estar errado. Sei que, em teoria, você deve sempre tentar torná-lo perfeitamente compatível, mas, realisticamente, alguém sabe o quanto é importante incluir esse recurso?

obrigado

Sempre escreva plug-ins para a versão atual e lembre-se das versões noturnas das próximas versões. Qualquer outra coisa não importa.

Editar Como @toscho apontou em um comentário:

Pode haver alguma explicação necessária para por que é assim.

1. Porque eu digo isso.
2. Os plug-ins precisam apenas ser compatíveis com o núcleo, porque se todos brincarem com as regras, nada falhará. Se um plugin não brinca com as regras, ele possui um bug . E esse bug precisa ser corrigido, e nada mais, e não outro plugin ou tema.
3. Usuários que não atualizam o WordPress são resultado de plug-ins de buggy usados ​​e não podem ser abandonados em sistemas sem muito trabalho. Como está escrito em (2), são erros com os quais você não precisa se preocupar. Os erros precisam ser corrigidos, não o seu plug-in, considerando o código de terceiros quebrado.
4. O código legado não precisa de suporte. Precisa de substituição. Não é o seu problema.
5. As coisas mudam em larga escala nas principais versões XX. Quando você tenta oferecer suporte a versões anteriores, geralmente precisa de soluções alternativas diferentes e muita verificação de versão. Ou seja, (a) um pesadelo de manutenção (b) aumenta a base de código (c) impossibilita os testes de unidade, pois eles precisam ser executados em uma versão - nem menos, nem mais e, finalmente, (d) diminuem o espaço em disco e o desempenho do servidor (em maioria dos casos).
6. O WordPress já possui uma base de código muito antiga que carece de melhorias em muitas arestas e cantos. Em resumo: o WordPress é antigo, usa no mínimo uma versão PHP não suportada e, portanto, você já suporta versões anteriores em níveis muito mais baixos do que na API pública do seu aplicativo.

Agora vá se perguntar:

Quando você já está suportando uma versão PHP não mais suportada, por que você deseja oferecer suporte a um aplicativo que nem mesmo é suportado por seus criadores?

Lembre-se do lançamento do WordPress 3.0 necessário para o PHP5. Na época, muitas empresas de hospedagem ainda não estavam executando o PHP5 em seus servidores. Portanto, houve um período em que alguns sites do WordPress NÃO PODERAM atualizar para o WordPress 3.0 porque suas empresas de hospedagem não mantinham seus servidores atualizados.

Muitos anos se passaram (3+) desde o lançamento do WordPress 3.0, portanto, ser compatível com o WordPress <3.x não é plugins muito comuns.

A maioria das instalações do WordPress está desatualizada . Atualmente, apenas 5,2% de todas as instalações estão em execução na versão mais recente 3.6.
27,3% ainda estão na versão 3.0.

Você pode pensar que precisa dar suporte a essas versões antigas com código compatível. Mas pense nas implicações:

• Você precisa testar todas as versões oficialmente suportadas.
• Você precisa lidar com APIs incompatíveis, como o uploader de mídia, que mudou drasticamente na versão 3.5.
• Você faz com que seus usuários pensem que não há problema em atualizar o WordPress, porque ele ainda funciona.
• Você precisa de mais código, mais testes e mais tempo para o suporte fazer as mesmas coisas.

E os usuários provavelmente nem instalarão seu plug-in porque sabem que novos plugins quebram o site. Em termos de alcance de mercado, você pode ganhar um pouco com código compatível com versões anteriores. Em termos de eficiência, você perde.

Minha regra geral para plug-ins que eu escrevo é o suporte para a versão atual menos 1, então todos os plug-ins que eu escreveria seriam compatíveis com 3.6.xe 3.5.x. Embora um plug-in específico possa funcionar em versões anteriores, eu não o garanto ou o suporte se você tiver problemas.

Há quatro meses, assumi a manutenção de um plugin popular. Antes de começar a trabalhar nele, o plugin não era atualizado há dois anos. Fiz várias correções, lançou a nova versão e, dois dias depois, ouvi um cara que disse que a nova versão causou a tela branca da morte em seu site. Depois de analisar, ele ainda estava executando o WordPress 2.9.2, e minha atualização usou a função home_url, introduzida no 3.0. Não sei por que o cara decidiu atualizar esse plug-in imediatamente, mesmo que ele não atualizasse sua instalação do WordPress em três anos. Quando fiz a nova versão, nunca pensei em testar o WordPress 2.9.2.

Aqui está a moral da história: No arquivo readme.txt do seu plugin , existe um número de versão "Requer pelo menos" no cabeçalho. Use-o. À medida que você faz atualizações, se não quiser testar versões antigas, aumente. Isso desencorajará os usuários que se recusam a atualizar suas instalações do WordPress de atualizar seu plug-in.

Atualmente, estou escrevendo um novo plug-in relacionado e planejando torná-lo apenas para o WordPress 3.6, porque quero usar a biblioteca getid3 incluída no núcleo. Não desejo lançar um novo plug-in para uma versão principal antiga.