Fix mininal version check for object_detection.md
Author: jajupmochi
Pull request: yes

# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

Add `check_min_version("4.42.0.dev0")` to `object_detection.md`. 


## Before submitting
- [X] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker and @younesbelkada
- vision models: @amyeroberts
- speech models: @sanchit-gandhi
- graph models: @clefourrier

Library:

- flax: @sanchit-gandhi
- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- pipelines: @Narsil
- tensorflow: @gante and @Rocketknight1
- tokenizers: @ArthurZucker
- trainer: @muellerzr and @SunMarc

Integrations:

- deepspeed: HF Trainer/Accelerate: @muellerzr
- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization (bitsandbytes, autogpt): @SunMarc and @younesbelkada

Documentation: @stevhliu and @MKhalusova

HF projects:

- accelerate: [different repo](https://github.com/huggingface/accelerate)
- datasets: [different repo](https://github.com/huggingface/datasets)
- diffusers: [different repo](https://github.com/huggingface/diffusers)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Maintained examples (not research project or legacy):

- Flax: @sanchit-gandhi
- PyTorch: See Models above and tag the person corresponding to the modality of the example.
- TensorFlow: @Rocketknight1

 -->


Comments:
Hi @jajupmochi, thanks for opening this PR! 

The scripts themselves should contain minimal version checks within them, which will trigger when running the scripts, but this isn't something we want to add to the general guides. 

> Hi @jajupmochi, thanks for opening this PR!
> 
> The scripts themselves should contain minimal version checks within them, which will trigger when running the scripts, but this isn't something we want to add to the general guides.

Hi @amyeroberts, thanks for the explaination. Perhaps it can be mentioned somewhere temporarily in the guide the minimal version required to execute the containing codes, or maybe add a link somewhere pointing to the script with version check?

I understand the importance of keeping the guide clear and focusing on the main topic. however it is quite troublesome for users, especially new comers to tackle the version problem. It took me quite sometime to make the code working cause some parts require a dev version to run. The rapid evolution of the library makes it even more difficult. From my observation, this is the case for many deep learning libraries. It would be much appreciated if this problem can be alleviated.

@jajupmochi I understand your frustration and we do want to make sure that the process is as smooth as possible for our users. 

To provide a bit more context, the `min_version_check` logic is something which we include in our example scripts. This provides a programatic check to make sure when the script is being executed, the installed version in the environment is compatible with the script. This is automatically updated whenever [we prepare a release](https://github.com/huggingface/transformers/commit/b6eb708bf1903f40499558b64e6d9392c1b889e1). It's also something which almost no users ever see, as most users will just execute e.g. `python run_clm.py --arg1 foo --arg2 bar`, and so acts as a guardrail. 

The purpose of the documentation guides is slightly different. Instead of a a script, it provides step-by-step guidance which, as you point out, we want to keep clear. Importantly, specifying the version doesn't provide much protection. There's five version installations the user could be working from: 
* Stable release v4.41.2- they will not see this information, nor have the fixes applied
* Installed from source before fixes - same as above
* Installed from source after fixes before this PR - documentation code now runs (user unaware of prev bugs and subsequent fixes)
* Install from source after this PR - code runs, they have this warning but already working from source 
* Stable release v4.42.0 - code runs, working from stable release but dev specification (possibly confusing and redundant)

Adding this means that we have to remember to go back and update (maintenance burden) and I suspect might be confusing to users, as most install directly from the stable releases on pypi. 

The best, and least complicated thing we can do is fix bugs as soon as we find them and release regularly. In fact, this is how we treat all of the library code: we don't put advisories every time we push a bug fix to `main` to install the dev version. 

> @jajupmochi I understand your frustration and we do want to make sure that the process is as smooth as possible for our users.
> 
> To provide a bit more context, the `min_version_check` logic is something which we include in our example scripts. This provides a programatic check to make sure when the script is being executed, the installed version in the environment is compatible with the script. This is automatically updated whenever [we prepare a release](https://github.com/huggingface/transformers/commit/b6eb708bf1903f40499558b64e6d9392c1b889e1). It's also something which almost no users ever see, as most users will just execute e.g. `python run_clm.py --arg1 foo --arg2 bar`, and so acts as a guardrail.
> 
> The purpose of the documentation guides is slightly different. Instead of a a script, it provides step-by-step guidance which, as you point out, we want to keep clear. Importantly, specifying the version doesn't provide much protection. There's five version installations the user could be working from:
> 
> * Stable release v4.41.2- they will not see this information, nor have the fixes applied
> * Installed from source before fixes - same as above
> * Installed from source after fixes before this PR - documentation code now runs (user unaware of prev bugs and subsequent fixes)
> * Install from source after this PR - code runs, they have this warning but already working from source
> * Stable release v4.42.0 - code runs, working from stable release but dev specification (possibly confusing and redundant)
> 
> Adding this means that we have to remember to go back and update (maintenance burden) and I suspect might be confusing to users, as most install directly from the stable releases on pypi.
> 
> The best, and least complicated thing we can do is fix bugs as soon as we find them and release regularly. In fact, this is how we treat all of the library code: we don't put advisories every time we push a bug fix to `main` to install the dev version.

@amyeroberts Thank you! 

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.