Atualização do OJS 3.6: testes do fluxo editorial

Atualização do OJS 3.6: testes do fluxo editorial

A atualização do OJS 3.6 exige separar o anúncio de uma decisão de mudança. O PKP apresenta a 3.6 como uma versão próxima: sua primeira entrega está programada para o outono de 2026, e não como um lançamento já disponível.[3] Enquanto isso, o OJS 3.5 é a LTS vigente e com suporte; a 3.6 pertence à linha STS prevista.[1]

A decisão razoável não é agendar a produção por causa de uma apresentação. É montar um teste reproduzível com uma cópia protegida da revista, uma amostra editorial exigente e critérios explícitos para avançar ou voltar atrás.

Diagrama próprio. Resume a sequência de ensaio antes de qualquer janela de produção.

Atualização do OJS 3.6: anúncio e disponibilidade

O OJS 3.6 foi anunciado pelo PKP, mas esse anúncio não equivale a uma versão lançada para instalação. O próprio comunicado identifica a entrega inicial como programada para o outono de 2026.[3] Até que o PKP publique a versão e seu material de lançamento, não convém transformar o anúncio em uma data comprometida para produção.

A página de lançamentos do PKP marca o OJS 3.5 como LTS com suporte. Também explica que as ramificações ímpares, como a 3.5, correspondem a LTS, enquanto as pares, como a 3.6, são STS.[1] Para uma revista que precisa de uma base com suporte agora, a 3.5 continua sendo a referência vigente. O caminho de atualização para a 3.5 está explicado no guia de migração da OJS ONE.

A novidade anunciada para a 3.6 é relevante para a produção editorial: um editor HTML integrado e a geração de HTML, PDF e JATS XML a partir do HTML como fonte canônica.[2] O PKP também declara que o fluxo tradicional com ferramentas de desktop ou serviços externos continuará disponível.[2] Por isso, um teste deve comparar o caminho integrado com o processo que a revista já consegue operar, sem presumir que este último desaparece.

Levante um inventário que permita decidir

O inventário não é uma lista administrativa. É a base para reproduzir a plataforma, reconhecer dependências e definir o que cada papel validará. Faça-o antes de criar o staging e deixe uma pessoa responsável por cada item.

• Registre a versão exata do OJS, PHP, banco de dados, servidor web, extensões e tarefas agendadas.
• Liste revistas, caminhos de arquivos privados e públicos, espaço usado, configuração, certificados, e-mail e cron.
• Identifique plugins ativos, sua função editorial, dependência, mantenedor e alternativa caso falhem.
• Documente o tema, o CSS, os modelos modificados, as alterações no código e os componentes de análise ou identidade.
• Mapeie depósitos de DOI, OAI-PMH, autenticação, e-mail, armazenamento e integrações que trocam dados.
• Marque quais usuários validarão submissão, avaliação, revisão, produção, publicação e leitura.
• Guarde evidência de um backup recuperável do código, da configuração, dos arquivos e do banco de dados.

O guia de migração da OJS ONE lembra que uma recuperação exige software, configuração, arquivos privados, arquivos públicos e banco de dados.[4] Não basta confirmar que existe um arquivo compactado. Restaure a cópia em uma instância isolada, abra uma prova de leitura, baixe um arquivo e verifique se as relações editoriais continuam presentes. Esse ensaio é a evidência útil para uma reversão.

Prepare staging, plugins e tema sem expor a revista

O staging deve ser uma cópia separada, com acesso restrito, indexação bloqueada, e-mail de saída controlado e conectores externos em modo seguro. Seu objetivo é observar a mudança sem notificações involuntárias, depósitos reais nem alteração de dados externos.

Crie uma matriz simples para plugins e tema. Na primeira coluna, escreva o componente e a versão. Depois registre função, evidência de compatibilidade quando for publicada, resultado do ensaio, responsável e decisão: manter, substituir, desativar ou escalar. Aplique o mesmo critério a um tema filho, CSS próprio e modelos. Um portal pode abrir a página inicial e ainda assim esconder uma falha em um formulário, uma tarefa automática ou uma prova de leitura.

Nesta etapa, não substitua processos estáveis por antecipação. O PKP aponta que o editor integrado será uma alternativa dentro do software e que o fluxo anterior permanece disponível.[2] Mantenha o processo vigente durante o ensaio e defina a condição que permitiria testar a nova alternativa depois de um lançamento efetivo.

Use uma amostra que pressione o fluxo editorial

Um teste breve com texto simples fornece pouco sinal. Selecione uma amostra controlada que represente os casos difíceis da revista: artigo com resumo bilíngue, autores com identificadores, referências extensas, tabela com células mescladas, equação, figura com legenda, link interno e correção na etapa editorial. Use cópias autorizadas ou material fictício; não exponha manuscritos nem dados pessoais.

O PKP antecipa que, durante a transformação, os layouts de tabelas e fórmulas são preservados, mas adverte que estilos complexos ou atípicos podem não ser transformados perfeitamente.[3] A amostra deve verificar esse limite de forma visível. Não a reduza a uma única prova de leitura em PDF.

Para cada caso, defina o resultado esperado e a evidência:

1. Envie ou carregue o arquivo de teste e confirme que o corpo é convertido em HTML editável, se a função estiver disponível.
2. Revise títulos, listas, tabelas, equações, figuras, texto alternativo, links e referências.
3. Gere HTML, PDF e JATS XML quando a função existir, e compare-os com o material de entrada e o resultado da publicação.
4. Corrija uma referência, uma célula e uma fórmula; gere os arquivos novamente e verifique o que é atualizado.
5. Percorra atribuição editorial, avaliação, revisão, produção e publicação com contas de teste.
6. Verifique a visualização pública, o download das provas, os metadados, o OAI-PMH, o e-mail e as tarefas que afetam essa revista.
7. Registre capturas de tela, mensagens de erro, arquivos gerados e uma decisão para cada defeito detectado.

O anúncio do PKP explica que apenas o corpo do artigo é compartilhado com o editor integrado e que os metadados aparecem em uma barra lateral.[2] Por isso, valide separadamente título, autores, resumo, identificadores e referências, em vez de concluir que a conversão do corpo comprova o registro completo.

Capacite por tarefa, não por tela

A capacitação deve ocorrer no staging e com a mesma amostra usada na aceitação. Atribua exercícios por papel: quem recebe manuscritos deve carregar e detectar problemas iniciais; quem revisa deve editar corpo e referências; a produção deve revisar a saída de cada formato; quem administra deve observar erros, tarefas, permissões e restauração.

Peça que cada participante conclua uma operação e deixe evidência: uma prova de leitura revisada, um dado corrigido, uma ocorrência documentada ou uma recuperação ensaiada. Essa abordagem revela dúvidas de operação antes de uma janela de mudança e evita que a equipe aprenda com submissões reais.

Inclua um guia breve de decisão. Ele deve indicar quando usar o caminho habitual, quando testar a função integrada e a quem escalar se uma tabela, fórmula ou estilo perder fidelidade. A meta não é forçar um único procedimento: é manter o controle editorial enquanto a ferramenta muda.

Defina aceitação e reversão antes de intervir

Não programe a produção até acordar qual resultado permite seguir e qual sinal obriga a parar. A lista de aceitação deve incluir acesso por papel, arquivos de teste, estado de submissões e avaliações, visualização pública, e-mail, tarefas agendadas, plugins usados, tema, integrações e metadados. Cada teste precisa de responsável, evidência e critério de aprovação.

A reversão exige um ponto de corte. Defina quando as mudanças editoriais são congeladas, quem autoriza abrir ou fechar a janela, qual cópia consistente será restaurada e como serão registradas as ações ocorridas durante o ensaio final. Se uma atualização altera o banco de dados, voltar apenas o código anterior não recupera uma plataforma consistente. O guia da OJS ONE recomenda recuperar um conjunto coerente de código, configuração, arquivos e dados.[4]

Encerre o plano com uma decisão explícita: continuar, repetir o ensaio, manter a 3.5 LTS ou restaurar a cópia. Esperar um lançamento efetivo da 3.6 não é inação; permite fazer o teste sobre o software que realmente seria instalado.

Erros que convém evitar

O primeiro erro é dizer que o OJS 3.6 já foi lançado. A fonte do PKP fala de uma primeira entrega programada, por isso a comunicação interna deve usar “anunciado” ou “previsto”.[3]

O segundo erro é testar com uma revista vazia. As transformações são avaliadas com tabelas, fórmulas, referências e estilo representativo, especialmente porque o PKP identifica possíveis limites em estilos complexos.[3]

O terceiro é chamar de backup uma cópia que não foi restaurada. A recuperação é validada restaurando em uma instância separada e verificando dados e arquivos, e não apenas constatando que o backup terminou.

O quarto erro é capacitar depois da mudança. O staging permite praticar, coletar ocorrências e ajustar instruções sem afetar publicações nem comunicações reais.

Perguntas frequentes

O OJS 3.6 já está disponível para produção?

Não. Em 23 de outubro de 2026, a comunicação do PKP situa a primeira entrega da 3.6 no outono de 2026.[3] Consulte a página de lançamentos e o material de lançamento antes de escolher uma versão para instalar.

Por que manter o OJS 3.5 enquanto se avalia a 3.6?

Porque a 3.5 aparece como LTS com suporte na página de lançamentos do PKP.[1] A avaliação da 3.6 pode avançar no planejamento e no desenho dos testes, sem substituir uma base vigente por uma versão anunciada.

O que deve conter a amostra de testes?

Inclua tabelas, fórmulas, referências, figuras, links, correções e a publicação de HTML, PDF e JATS XML quando essa função estiver disponível. Assim você poderá comparar o resultado com o material que a revista processa e detectar limites de estilo.[3]

Avalie a atualização com acompanhamento técnico

Se você precisa organizar inventário, staging, backup, testes e reversão antes de uma atualização, conheça o serviço de operação OJS. O escopo é definido de acordo com a instalação, seu fluxo editorial e as evidências reunidas no ensaio.

Fontes

1. PKP, PKP Software Releases — consultado em 2026-10-23.
2. PKP, OJS 3.6: Bringing Manuscript Editing and Production under one Roof — consultado em 2026-10-23.
3. PKP, Upload, Transform, Publish: Inside OJS 3.6’s File Production and Toolset — consultado em 2026-10-23.
4. OJS ONE, Atualizar o OJS para a 3.5 LTS: requisitos e caminho de migração — consultado em 2026-10-23.