Long number string variables are now converted to scientific notation, breaking existing tasks that expect the number as is

[manzamor-cs]

Existing commands that utilize a long number variable as a string are now broken by conversion to scientific notation.

Given this task:

  long-number:
    desc: Print a long number variable
    vars:
      LONG_NUMBER: 123456789012345678901234567890
    cmds:
      - echo "{{.LONG_NUMBER}}"

Using task version 3.36.0:

❯ task long-number      
task: [long-number] echo "123456789012345678901234567890"
123456789012345678901234567890

Using task version 3.37.2:

❯ task long-number 
task: [long-number] echo "1.2345678901234568e+29"
1.2345678901234568e+29

The issue can fixed by just quoting the variable that is meant to be interpreted as a string, but this does break previously existing tasks that utilize unquoted long numbers.

• Task version: 3.37.2
• Operating system: Mac OS/Linux
• Experiments enabled: Nope

[pd93]

This is behaving as intended. Since Task now supports any scalar variable type, if you give it a number, it will be interpreted as one (rather than the previous behaviour which automatically converted it to a string). Since the number you used far exceeds the maximum signed and unsigned 64 bit integer size, it is converted to a float approximation instead and when printed it will be displayed using scientific notation.

If you want your variable to be a string then you should always wrap it with quotes and it will be interpreted as expected:

  long-number:
    desc: Print a long number variable
    vars:
      LONG_NUMBER: "123456789012345678901234567890"
    cmds:
      - echo "{{.LONG_NUMBER}}"

[manzamor-cs]

I figured this might be the intended behavior and included the bit about the quotes after the example I provided. For future reference, should I assume minor version bumps could introduce breaking changes?

[pd93]

We don't (intentionally) make breaking changes in minor/patch versions. We follow SemVer rules for our CLI binary (Though it's worth remembering that the Golang package API does not share this compatibility guarantee). This is one of the reasons why we have experiment flags (for testing breaking changes to be made in future major releases).

I understand that this release made some Taskfiles behave differently. However, I would argue that this is still not considered to be a breaking change since it only changes the behaviour of incorrectly formatted YAML files. If anything, I would consider the previous behaviour to be buggy and we should have been erroring if we detected non-string variables.

The fact that in prior versions, you could define a YAML boolean and then not use {{if .BOOL_VAR}} when templating was not intuitive at all. Likewise, defining a YAML number without quotes implies that you should be able to do {{index (list 1 2 3) .NUM_VAR}}. However, this would have errored with cannot index slice/array with type string. In 3.37.0+ both these scenarios work as expected.

Sidenote: One of my least favourite things about YAML is that it lets you define strings without using quotes. It leads to a lot of problems/misunderstandings. Especially given that y, n, yes, no, on, off, true and false are all parsed as bools depending on the parser and YAML version you're using. It's just messy and should be avoided at all costs. There is plenty of discussion on this topic on StackOverflow.

One thing is for sure though. If you want a string containing numeric-only characters - you need to quote it.

[manzamor-cs]

I understand what you mean about the previous behavior being considered a bug. I guess whether this is considered a "breaking change" is open to interpretation, but I can definitely see your point. Thanks for the explanation! 👍🏻