Algum progresso nisso? Embora eu adore a funcionalidade de eventos recorrentes, sinto na pele a dor de ter que gerenciar manualmente o arquivamento dos eventos com frequência!
2 curtidas
Ainda não há nenhum progresso visível adicional no PR:
Ainda estou esperançoso de que a funcionalidade possa ficar no plugin de Eventos incluído, em vez de ter que mantê-lo separadamente.
Essa experiência anterior é também a razão pela qual estou um pouco cauteloso em manter isso localmente por um longo período.
No meu próprio auto-hospedagem, já uso um hook after_code para um pequeno backport de um PR upstream. O hook primeiro verifica por marcadores indicando que a funcionalidade foi implementada upstream. Se não foi, ele baixa o patch para um commit conhecido, executa git apply --check e só então aplica-o com git apply.
Isso funciona razoavelmente bem enquanto o patch continua compatível com o núcleo, mas já tive uma versão anterior desse backport de parar de aplicar à medida que o núcleo evoluiu. Uma reconstrução falhou e o container permaneceu offline até que eu removesse o hook.
Para essa mudança específica, se eu precisasse de um fallback temporário, provavelmente forneceria um backport via after_code da mesma forma, em vez de empacotá-lo como um plugin separado.
A razão é que o #43187 já modifica o próprio caminho de rolagem agendada no lado do servidor do plugin de Eventos incluído. Um hook after_code pode aplicar essencialmente o mesmo patch upstream diretamente durante a reconstrução. Um plugin separado precisaria recriar essa integração por meio de um ponto de extensão, ou de outra forma anteceder/substituir o comportamento interno do MonitorEventDates, o que adiciona outra camada e pode ser igualmente frágil.
A desvantagem da abordagem after_code é que ela ainda está atrelada à forma exata do código upstream. Como o comportamento de tópico sucessor afeta o MonitorEventDates, o mesmo patch de commit fixo pode continuar a ser usado por enquanto o git apply --check tiver sucesso. Se o upstream alterar esse código o suficiente para que o contexto do patch pare de corresponder, precisarei fazer o rebase ou adaptar a mudança para o main atual, criar um novo commit e atualizar o hook para usar esse novo SHA de commit.
Então, minha preferência permanece:
- mesclar a funcionalidade de sucessor no plugin de Eventos incluído; ou
- se a equipe preferir que o comportamento permaneça externo, expor um hook suportado em torno da rolagem de eventos recorrentes.
Até lá, um patch after_code seria um fallback prático e temporário para auto-hospedagem, mas não o consideraria o mecanismo de distribuição ideal a longo prazo.
3 curtidas