Remove an obsoleted logic from CmaEsSampler

[c-bata]

Motivation

Follow-up #4184. See #4184 (comment) for details.

Description of the changes

Remove the logic to keep the compatibility for Optuna v2.5 or older.

[c-bata]

@contramundum53 @eukaryo Could you review this PR?

[codecov-commenter]

Codecov Report

Merging #4239 (5ce92bb) into master (dcbb316) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #4239      +/-   ##
==========================================
+ Coverage   90.42%   90.43%   +0.01%     
==========================================
  Files         172      172              
  Lines       13659    13657       -2     
==========================================
  Hits        12351    12351              
+ Misses       1308     1306       -2     

Impacted Files	Coverage Δ
optuna/samplers/_cmaes.py	99.11% <100.00%> (-0.01%)	⬇️
optuna/integration/botorch.py	97.55% <0.00%> (+0.81%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[contramundum53]

LGTM!

[github-actions]

This pull request has not seen any recent activity.

[c-bata]

Let me add no-stale label to avoid this unintentionally being closed.

[toshihikoyanase]

@c-bata Could you resolve the conflict, please?
@eukaryo If you are busy, please feel free to remove the assignment.

[c-bata]

I resolved the file conflict. Let me reassign reviewers.

@HideakiImamura Could you review this PR if you have time?

[HideakiImamura]

Thanks for the PR. The change looks good to me.

Let me ask one question. Does this change align with our deprecation policy? When we conduct breaking changes in the stable feature, we have a deprecation period over 2 major versions. As long as I can see, the CmaEsSampler has been stable from v2.0.0. Should we have a deprecation period with prior notice for users on this change?

[c-bata]

@HideakiImamura Thank you for your review. That's a good point. It may be a bit controversial whether this change is considered as a breaking change.

First, there is no change in terms of the interface, so the user programs will not be broken. Second, in terms of optimization performance, there is a possibility that some user programs will perform worse. It is extremely rare cases like the following though.

1. Created a study and executed an optimization using CMA-ES with Optuna v2.5 or prior
2. Then, did not execute an optimization using CMA-ES with Optuna v2.6-v3.0
3. Then, executed an optimization using CMA-ES of this PR.

I think this change is acceptable, but if you think it is a breaking change, this PR can be merged in v4.0 or v5.0. What do you think?

[HideakiImamura]

Thanks for the explanation. I agree with merging this PR in this release. LGTM.