Repository: transformers
Issue: Identifying backend compatibility versions
Labels: WIP

We are currently working on identifying the backend versions with which we are compatible and with which we want to be compatible. These backends are PyTorch and TensorFlow. We will be considering Flax at a later point in time.

The first step was to identify the number of failures in each PyTorch/TensorFlow version and was done in https://github.com/huggingface/transformers/issues/18181.

Total number of tests: 38,991.

|     Framework | No. Failures | Release date | Older than 2 years |
| :--------------- | ---------- |  ---------- |  ---------- |
|  PyTorch 1.10 |           50 | Mar 10 2021 | No |
|  PyTorch  1.9 |          710 | Jun 15 2021 | No |
|  PyTorch  1.8 |         1301 | Mar 4 2021 | No |
|  PyTorch  1.7 |         1567 | Oct 27 2020 | No |
|  PyTorch  1.6 |         2342 | Jul 28 2020 | Yes |
|  PyTorch  1.5 |         3315 | Apr 21 2020 | Yes |
|  PyTorch  1.4 |         3949 | Jan 16 2020 | Yes |
| TensorFlow 2.8 |          118 | Feb 2 2022 | No |
| TensorFlow 2.7 |          122 | Nov 4 2021 | No |
| TensorFlow 2.6 |          122 | Aug 11 2021 | No |
| TensorFlow 2.5 |          128 | May 13 2021 | No |
| TensorFlow 2.4 |          167 | Dec 14 2020 | No |

We're proposing to drop versions older than 2 years old and to work towards providing support (support = 0 tests failing) for versions we aim to support. We will drop support for older versions once we reach their two-year-old date. 

Here is the proposed plan moving forward:
- [ ] Have a detailed breakdown of failures for the following versions: 
    - [ ] Torch 1.7
    - [ ] Torch 1.8
    - [ ] Torch 1.9
    - [ ] Torch 1.10
    - [ ] Torch 1.11
    - [ ] Torch 1.12
    - [ ] TensorFlow 2.4
    - [ ] TensorFlow 2.5
    - [ ] TensorFlow 2.6
    - [ ] TensorFlow 2.7
    - [ ] TensorFlow 2.8
    - [ ] TensorFlow 2.9
- [ ] Start with an initial compatibility document to mention which models are supported in which versions
- [ ] Open good first issues to improve compatibility for models not compatible with all versions, starting from the latest one and moving back in time.
- [ ] As versions become supported, run tests on older versions to ensure no regression.

Work by @ydshieh and @LysandreJik 

----------

### Some context and tips when working on Past CI

1. The Past CI runs against a specific commit/tag:
    - **Motivation**: To be able to run the test against the **same** commit to see if a set of fixes improves the overall backward compatibility without new issues introduced.
    - The chosen commit could be changed (to more recent ones) along the time, but it should never be `main`.
    - When working on the fix for Past CI , keeping in mind that we should **check the source code in the commit that is chosen for that particular Past CI run**. The commit given at the beginning of each report provided in the following comments.
2. For each report, there is an attached `errors.txt` where you can find more information to ease the fix process:
    -  The file contains a list whose elements have the following content:
        - The line where an error occurs
        - The error message
        - The complete name of the failed test
        - The link to the job that ran that failed test
    - The errors in the reports sometimes don't contain enough information to make the decision/action. You can use the corresponding links provided in `errors.txt` to see the full trackback on the job run pages.
3. One (possible) fix process would be like:
    - For a framework and a particular version, go to the corresponding reporting table provided in the following comments.
    - Make sure you have a preferred way to navigate the source code in a specific commit.
    - Download/Open the corresponding `errors.txt`.
    - From the `General` table, take a row whose `status` is empty. Ideally, take the ones with higher value in `no.` column.
    - Search in `errors.txt` for the `error` in the picked row. You get information about the failed line, failed test, and the job link.
    - Navigate to the failed line or failed test in your workspace (or in a browser) that checks out to the specific commit for the run.
    - Use the job link to go to the job run page if you need more information about the error.
    - Then you might come up with a solution :-), or decide a fix is not necessary with good reasons.
    - Update the `status` column with a comment once a fix or a decision is made.
4. Some guides/hints for the fix:
    - 🔥 To install a specific framework version, `utils/past_ci_versions.py` can help!
    - ⚠️ As the tests are run against a chosen commit, which may not contain some fixes in the `main` branch. (This is particular confusing if you try to run the failed test without checking out to that commit.).
        - If the test passes when you run a failed test (in the report) against the `main` branch, with the target framework version, it's very likely a fix exists on `main` that applies to the target framework version too.
        - In this case,
            - either update `status` with `fixed in #XXXXX` (if you know clearly that PR fixes that error)
            - or `works for commits since **b487096**` - a commit sha (It's not always trivial to find out which PR fixed a particular error - especially when working with Past CI) 
    - We decide to focus on the PyTorch and TensorFlow version, and not to consider other 3rd libraries.  Therefore, some packages are not installed, like `kenlm` or `detectorn2`. We could just simply update the `status` column with `XXX not installed`.
    - When an error is coming from a C/C++ exception, and the same code and inputs work for new framework versions, we could skip that failed test with a `@unittest.skipIf`, and update the status like `torch._C issue -> works wth PT >= 11 Fixed in #19122`.
        - PR [#19122](https://github.com/huggingface/transformers/pull/19122) is one such example.
    - If an error occurs in several framework versions, say, PT 11 and PT 10, and a status is updated for the newer version (here PT 11), we can simply put `see PT 11` in the report `status` column for older versions.
    - Some old framework versions lack attributes or arguments introduced in newer versions. See [#19201](https://github.com/huggingface/transformers/pull/19201)  and [#19203](https://github.com/huggingface/transformers/pull/19203) for how a fix would look like in such cases. If a similar warning (to the one in [#19203](https://github.com/huggingface/transformers/pull/19203)) already exists, we could update `status` with, for example, `Vilt needs PT >= 1.10`.
        - Adding such warning is not a fix in a strict sense, but at least it provides some information. Together with the updated `status`, we keep information tracked.