Louis CAD

That's why we provide dependency notations with version keys for many dependencies related to the Kotlin ecosystem.

It's partly true, and we're fine with that. However, the approach you're suggesting doesn't scale so well either as it requires more manual work to update dependencies versions.

I prefer to be honest, I don't see myself spending hours and days on such a feature which I believe provides an inferior UX to what we already have, especially...

@nkiesel Thanks for your thoughts, I'm still not sure a Kotlin DSL is the right approach, but your point of view gives food for thoughts. I'll keep this issue updated...

YAML is very error-prone as it cannot be automatically formatted and just an extra space can break it in hard to read way. I'm forced to use it in GitHub...

The fact that it's used by many is not an argument I consider. That'd just keep the trend, and I do not want to keep it going since it has...

After some dogfooding, here's what I found out: Reporting hardcoded versions on the fly (when version placeholder replacement is performed) is not good, because it makes warnings recurrent, even though...

Thanks for the report! Indeed, for simplicity (on my end), dots and dashes are treated the same for now. That gives more examples to tune a better version sorter. ###...

We can still tweak the version ordering system some day, because the scheme described here is quite common. I might do it sometime next year as a mental exercise.

Nice catch, it looks like we missed it while reviewing our work on AndroidX dependency notations. it should be a `DependencyNotationAndGroup`. I'll fix it for the next release.