Please update the filename to reflect the version change: 2022_0.nix -> 2022_1.nix.

Also the top-level definition will need to be updated to point to the new file:

https://github.com/Saterfield990/nixpkgs/blob/69fe759b6328afd507c3b984d1e1d2bc1dc6ba5c/pkgs/top-level/all-packages.nix#L6106

Is there any reason to have the file name 2022_1.nix instead of 2022.nix besides just being just more steps to do?
Like... I would understand if a specific version were to be added besides what is existent, but to name it after the whole version does not make sense to me.
In the end, it's just more work to go through all the files that define it with that specific version, each time an update is done and prior version is not kept as well.

I don't know why it was done this way but I guess whoever added it probably just followed existing convention.

It should be fine to rename it to 2022.nix (and rename the corresponding top-level) to avoid extra steps in the future. But I don't think we ought to leave it named as 2022_0 if the actual version is 2022_1.

Ideally at some point in the not too distant future we can remove all the older versions and just have a single tbb.

I renamed both the file and in top-level to 2022 since renaming just the file still made it fail for all other packages that have tbb_2022_0 in them, which is exactly the problem with having the default and only one be the whole version in name.

At the same time the checks are complaining about lint(deprecation but not failure). Maybe it would be good to also move it to by-name as it recommends?
tbb 2020 -> pkgs/by-name/tb/tbb_2020/package.nix
tbb 2021 -> pkgs/by-name/tb/tbb_2021/package.nix
tbb 2022 -> pkgs/by-name/tb/tbb_2022/package.nix

Instead of removing it and relocating the file I would prefer we change it to this:

tbb_2022 = callPackage ../development/libraries/tbb/2022.nix { };

The linter complaining is okay to ignore in this case and isn't a blocker. For maintenance and clarity reasons its better to follow the existing convention here.

Once that's changed it should be good to merge.

I'm indifferent to whether we go to by-name or not, but I do think that we should do the same thing for all 3.

Dropping the minor version number from the attribute / file name is good.

Okay, well then I will leave it up to @Saterfield990.

The reason I was hesitant is because there doesn't seem to be much precedent for named versions under by-name from what I saw at a glance.

But anyway, once all three are consistent whichever way, we should be able to merge.

Alright, then let's move all of them to pkgs by-name, instead of using a deprecated way so we have green on all checks.

I have created the following:
#402508
#417775

At the same time, I will have to ask the following:

So I think the best thing to do here is to keep the default.nix here as-is, then add 2021_13.nix under the tbb/ dir as a new version. Then add a new top-level alias for it in the same spot that I link to.
Then either in a separate commit or PR we can update all existing packages that reference tbb_2021_11 to use tbb_2021_13, and if there is breakage found, at least those dependent packages can roll back to _11

If tbb is so sensitive and has had problems in the past with version updates, instead of keeping two versions or more for the packages that don't like the lastest one, wouldn't it be better for those packages to do something like this in the buildInputs?

(tbb_2021.overrideAttrs (oldAttrs: {
  version = "2021.11.0";
  src = fetchFromGitHub {
    owner = "oneapi-src";
    repo = "oneTBB";
    tag = "v2021.11.0";
    hash = "sha256-zGZHMtAUVzBKFbCshpepm3ce3tW6wQ+F30kYYXAQ/TE=";
  };
}))

and like that they can keep it locked to a specific working version as long as they want and until updating that version works.

You'd have to ask the other maintainers since I only recently added myself. But I agree it would probably be better to have isolated the affected packages and pinned specific tbb versions locally like that.

I have created the following:
#402508
#417775

Why not consolidate those into the single PR here? It's easier to track for the current discussion and to reference later if there's a problem.

Sure
I'll consolidate those PRs here
Funny how two more packages appeared in master since I last rebased on top of it