As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Registro de alterações do mecanismo WDL para HealthOmics
<a name="wdl-engine-change-log"></a>

Esta página contém o registro de alterações do mecanismo WDL tanto para o modo estrito da WDL quanto para o modo leniente da WDL. Cada seção resume novos recursos, aprimoramentos e suspensões de uso.

## Novos recursos e aprimoramentos
<a name="wdl-changelog-new-features"></a>

A tabela a seguir lista novos recursos e aprimoramentos para o mecanismo WDL ativado. HealthOmics


| Data da mudança | Alterar nome | Descrição da alteração | Recommended Action (Ação recomendada) | 
| --- | --- | --- | --- | 
| 22 de setembro de 2026 | Manipulação consistente do final de linha CRLF | HealthOmics corta Windows-style (`\r\n`) terminações de linha de forma consistente em`read_lines()`, e `read_tsv()``read_map()`, correspondendo ao comportamento das ferramentas padrão do Linux. | Nenhum. Não há necessidade de alterações no fluxo de trabalho. | 
| 22 de setembro de 2026 | `zip()`,`cross()`, e `read_tsv()` agora manipule corretamente as entradas de tipo misto. As soluções alternativas manuais de conversão de tipos podem ser removidas. | As funções integradas`zip()`,`cross()`, e `read_tsv()` agora inferem corretamente os tipos de seus valores de retorno. Nas versões anteriores, essas funções podiam produzir erros de tipo inesperados ao combinar tipos mistos (por exemplo, `Array[String]` e `Array[Int]` em uma `zip()` chamada), exigindo soluções alternativas manuais de conversão de tipos no código WDL. | Se seu fluxo de trabalho incluir conversões de tipo explícitas adicionadas para contornar erros de tipo de `zip()``cross()`, ou`read_tsv()`, você poderá removê-las. HealthOmics agora infere os tipos corretos automaticamente.<br />Manter as conversões de tipos existentes não causará erros nem afetará o comportamento do fluxo de trabalho. | 
| 22 de setembro de 2026 | `basename(path, "")`fix retorna o nome do arquivo em vez de uma string vazia. | `basename(path, "")`agora retorna o nome do arquivo.<br />Por exemplo, `basename("/path/to/file.txt", "")` retornará `"file.txt"` em vez de uma string vazia. | Pesquise `basename(x, "")` chamadas em seus fluxos de trabalho. Se houver algum, verifique se retornar o nome do arquivo é o comportamento esperado. | 
| 22 de setembro de 2026 | Float-key detecção de colisão em `collect_by_key()` | `collect_by_key()``Float`chaves anteriormente tratadas como idênticas se correspondessem a 6 casas decimais. Valores distintos, como `0.0000001` e, `0.0000002` foram mesclados em um grupo.<br />A partir da data de alteração, HealthOmics detecta essa colisão no momento da criação do fluxo de trabalho e falha no fluxo de trabalho com um erro claro no campo GetWorkflow StatusMessage em vez de descartar os resultados.<br />Um fluxo de trabalho que antes era concluído com êxito ao mesclar `Float` chaves distintas agora falhará com um erro de detecção de colisão, como `"statusMessage": "(collect_by_key_test.wdl Ln 17 Col 47) No such function: collect_by_key\n Map[Float, Array[String]] collected = collect_by_key(pairs_with_collision)"` | Você pode usar qualquer uma das três abordagens:+  Use `String` chaves: `Array[Pair[Float, String]]` `Array[Pair[String, String]]` altere e cite seus valores-chave. As teclas de string são sempre distintas e eliminam totalmente o risco de colisão. <br />+  Use `Int` teclas: altere o tipo de chave para `Array[Pair[Int, String]]` multiplicar seus valores flutuantes por uma potência de 10 para preservar a precisão necessária como números inteiros. <br />+  Se `Float` as chaves forem inevitáveis, arredonde-as primeiro para uma precisão consistente para garantir que cada chave seja realmente distinta e que nenhum dado seja mesclado silenciosamente. Normalize cada tecla usando `round(value * 1000000.0) / 1000000.0` antes de passar para o. `collect_by_key()`  | 
| Próximos (aviso prévio de 60 dias a partir de 22 de setembro de 2026) | A divisão flutuante (/) retornará números decimais, não números inteiros truncados. | **Comportamento atual: ** o `/` operador nos `Float` operandos retorna o inteiro mais próximo. Por exemplo, `5.0 / 2` devoluções`2.0`, não`2.5`. Se ambos os operandos forem `Int` (por exemplo,`5 / 2`), o resultado retornará 2.<br />**Próxima mudança (30 de novembro de 2026): ** A divisão flutuante nos operandos flutuantes retornará com precisão de 16 decimais. Após essa data, `5.0 / 2.0` retornará`2.5`, `150.0 / 7.0` retornará `21.428...` em vez de um valor inteiro.<br />A precisão do resultado depende de como ele é consumido: se o tipo de resultado for`Float`, o valor será calculado com até 16 dígitos decimais de precisão; se o resultado for coagido para a, `String` ele será formatado para 6 dígitos decimais.<br />Por exemplo`2.5`, `5.0 / 2.0` retornará e `150.0 / 7.0` retornará `21.4285714285714` como a`Float`, mas `21.428571` se interpolado em a. `String`<br />`Int / Int`expressões como não `5 / 2` são afetadas e continuarão retornando 2. | Para garantir resultados inteiros, independentemente da versão do motor, inclua a divisão flutuante em `floor()` ou: `ceil()`+  `floor(5.0 / 2.0)`→ sempre retorna `2` <br />+  `ceil(5.0 / 2.0)`→ sempre retorna `3` <br />Se seu fluxo de trabalho espera intencionalmente resultados decimais da divisão flutuante, nenhuma alteração é necessária. O próximo comportamento da divisão a partir de 30 de novembro de 2026 também retornará casas decimais.<br />Nota: `5/2` ainda retornará 2, pois o `/` operador é aplicado em números inteiros. |