Adjust deprecations behaviour for projects on dbt <=v1.9

[billwallis]

Summary (enhancement)

I've left the title intentionally vague to avoid an XY problem 😄

I love this tool, and I've been using it liberally on several of the dbt projects that I work on! (I'm a consultant and work across several clients)

However, I recently ran the deprecations command on a dbt project which is still on dbt v1.9 (I know this goes EOL in under two weeks) and it happily changed all the tests to use the arguments attribute, even though that attribute does not exist in dbt v1.9

This is totally user error on my behalf, but it would be awesome if the CLI could identify that I was on an older version of dbt and do something different to not break the YAML

I'm thinking either:

1. Warn me (and not run?) so that I know to update my dbt version first
2. Only run fixes appropriate for the current dbt version (e.g. the move_custom_configs_to_meta_sql refactor is fine for dbt v1.9)

Since v1.9 is going EOL very soon, I don't think (2) is worth the effort, but just mentioning it anyway in case there is interest in it 🤔

Would throwing a warning on EOL dbt versions be an appropriate behaviour for this tool?

[chayac]

Hi, thanks for your report! I chatted with the team and for some general context, the deprecations command is intended specifically to fix issues that are deprecated as of 1.10 and the fixes use functionality from dbt 2.0/Fusion. But 2.0 is only guaranteed to be backwards compatible to 1.10.6, so unfortunately autofix can't really guarantee compatibility before 1.10.6.

But! I agree that we need to be clearer about that. So I'd like to update the README (and perhaps the documentation in the CLI itself) to explicitly state that if you run autofix on a project lower than 1.10.6, it may introduce functionality that is not backwards compatible.

I also really like the idea of checking the local dbt version but (as you may already know from your clients) people put dbt binaries in all kinds of places with all kinds of different names, so finding the right binary to check the version from within a Python venv is apparently non-trivial.

If you don't mind though, I'd love to know some of the cases you've run into where autofix broke v1.9 projects - you mentioned the arguments attribute in tests as one example, are there any other major ones you've seen? We might be able to emit a warning or at least clarify the documentation for those specific fixes so people are aware it's incompatible with 1.9.