CompatHelper: add new compat entry for AbstractDifferentiation at version 0.5 for package docs, (keep existing compat)

[github-actions[bot]]

This pull request sets the compat entry for the AbstractDifferentiation package to 0.5 for package docs. This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Note: Consider registering a new release of your package immediately after merging this PR, as downstream packages may depend on this for tests to pass.

[devmotion]

IMO (as discussed in #101) we should not fix the version of AbstractDifferentiation in docs/Project.toml since this will be problematic when working on breaking releases. Rather, I'd suggest removing AbstractDifferentiation from the deps section - the first thing that's done on Github CI or when building locally, is adding the dev package at the repo anyway.

[gdalle]

Rather, I'd suggest removing AbstractDifferentiation from the deps section - the first thing that's done on Github CI or when building locally, is adding the dev package at the repo anyway.

The reason I disagree is that when you build locally, dev-ing the package changes docs/Project.toml to add the line you want to remove. Do you think there is a way around that?

[devmotion]

No, I don't know any. As long as you don't have any other changes in the Project.toml file locally, it's not a problem - you just should not commit them. I tend to think that the many annoyances with CompatHelper and breaking changes in CI outweigh the inconveniences the few times you actually build docs locally (I almost always only use CI).

[gdalle]

(I almost always only use CI).

I guess that's the root of our disagreement then, I always build locally ;)

Also note that the CI preview of the docs is only available for PRs from repo branches, and not for PRs from forks. That means outside contributors are forced to build locally, and they are also more likely to commit the changes to docs/Project.toml by mistake.

[devmotion]

they are also more likely to commit the changes to docs/Project.toml by mistake.

It's easy to notice it and tell them to revert the change when doing the PR review 🤷

[devmotion]

Since you build locally and it would be less convenient for you with the approach I commonly use, let's just merge this PR and re-evaluate if it becomes too inconvenient/problematic for CI.

[devmotion]

As mentioned above, the compat entry is problematic when working on breaking releases: https://github.com/JuliaDiff/AbstractDifferentiation.jl/actions/runs/6424726444/job/17445945926#step:4:18