Wes McNamee

I have first-class ideas for how to implement this in v4

@andreynering and others, a recent discussion that can provide some insight into this is here: https://github.com/go-task/task/discussions/700#discussioncomment-2527969

I just ran into the same problem. It seems that the only solution is to add `mage` to the custom tags as described here: https://www.jetbrains.com/help/go/configuring-build-constraints-and-vendoring.html# It looks like doing this...

What needs to happen is that vars of all sorts need to define their own expectations, similar to `make`. This variable will always have the value `bar` regardless of if...

Which cmd block above is problematic?

I'm getting some inconsistent behavior. And I found several bugs in the upstream yaml package that's used in `task`: https://github.com/go-yaml/yaml/issues/827 https://github.com/go-yaml/yaml/issues/804 https://github.com/go-yaml/yaml/issues/789 https://github.com/go-yaml/yaml/issues/387 The fix would be to identify a...

@andreynering please help me understand why you do not want breaking changes on v4. Fundamentally, the point of a major version bump is to allow changes that would otherwise be...

> unless it's an actual new feature. A common misconception is that naming things doesn't matter. In fact, well named fields and values make a ton of difference. So this...

For further clarification that in fact order of declaration of variables actually doesn't matter, here's another example: ```go for _, v := range []string{"1", "2", "3"} { varName := "var"...

> I could imagine a system that "compiles to GitHub Actions" There's https://github.com/nektos/act which is designed to run your the GitHub workflow _locally_. That's probably the closest you are going...