It appears you are maintaining your environment by issuing a series of conda install commands. You could continue to do this, with an additional version specification on the command line. But I encourage you to switch to this approach:

Create an environment.yml file that looks like this.

name: myproject

channels:
  - conda-forge

dependencies:
  - bzip2 >= 1.0.6
  - pip >= 19.1.1
  - snappy >= 1.1.7
  - zlib >= 1.2.11

Add others as needed.

Use conda env update to install the packages. (With which python you can see where they were installed.)

An advantage of this approach is you can easily rm -rf ~/miniconda3/envs/myproject/ (or wherever they were installed) and then conda env update to re-install from scratch. This typically resolves versionitis problems, or at least offers a hint about which version constraints should be relaxed to permit a feasible solution.

I personally favor >= constraints in my environment.yml files. Sticking to modern versions is good for community support when things go awry, and is good for speed of updates since conda will have just a handful of modern versions to consider, rather than trying to figure out how e.g. python2 might play into the dependency constraints. It helps me to learn of updates, and then I re-run my automated unit tests upon pulling in newer deps.

Alternatively you can routinely store == constraints to lock it down if desired, e.g. bzip2 == 1.0.6. And if you haven't been doing that, you can still checkout an old snapshot with e.g. bzip2 >= 1.0.5 and edit with global search-n-replace, changing >= to ==. That will set the controls on the Time Machine to go back in time to some consistent set of older dep versions. If your conda env update run shows some rough edges, consider nuking the environment and re-populating it from scratch. Often a clean install like that will run more smoothly.

Have you tried:

pip install <package>

or

conda install -c conda-forge <package>