Replace obsolete function argument name in docs for api.create_repo

[pavel-lexyr]

repo_id does not appear to work. Is name the newer version?

[adrinjalali]

Hi @pavel-lexyr , what makes you think name is the new version? name and organization are deprecated in favor of repo_id.

[osanseviero]

I do think it's an issue since the change has not been released but the docs were updated as in https://huggingface.co/docs/hub/adding-a-model#creating-a-repository-2

[LysandreJik]

Ah, good catch! I wasn't aware that the docs were automatically deployed.

This will change with #782 as the docs will be deployed on a version-basis to the stable docs, and the docs for main will be pushed to the main version of the docs (non-default).

[osanseviero]

The docs are updated when they are hub-docs sub-module is updated in moon landing

[adrinjalali]

So what's the path forward here? I don't think we want to merge this to main.

[LysandreJik]

@osanseviero mentioned that he would like to see the following PRs merged before the next release:

• Updates delete_repo with the updated endpoint http codes MNT more informative message on error in Hf.Api.delete_repo #783
• Disables logging with org token Disable logging in with organization token #780
• Keras callback Keras callback for pushing models to Hub #718
• Fastai Add fastai upstream and downstream capacities for fastai>=2.4 and fastcore>=1.3.27 versions #678

I personally would like to see #782 merged before the next release.

We can either:

• Release v0.5.0 right now to update the public facing API, and release v0.6.0 once all of these PRs have been merged (probably in ~1 week?). Downside to this is that we do two very fast consecutive releases. Not too bad given that we don't have a written statement of current timing between releases, and since we're not at v1.0 yet deprecation cycles between minor releases are theoretically nice-to-haves, even if we're very attached to them.
• Focus on merging the PRs above and release v0.5.0 then. We'll likely have an additional few days where the documentation is incorrect (but correct for the source install), but I personally think that's okay. It should be the last occurrence of such situations.

What do you think, @osanseviero, @adrinjalali?

[osanseviero]

IMO none of the PRs I mentioned are release-blocking so it is ok if we do two releases so our docs are in sync. We have also done a lot of interesting work since last release, so I think we can go ahead 😄

No strong opinion though.

[adrinjalali]

I'd rather wait for those PRs (maybe except #782, since I'm not sure how much work that is. It looks like that PR's gonna take a while to be merged).

I think we should have a slow-ish release cycle for this library since it's the core library used by all integrations, and the deprecation cycle should give people enough time to adapt their code. Having two releases in the span of a week doesn't give people enough time to adapt.

[osanseviero]

SGTM!

[LysandreJik]

This can be closed as the new release was done and repo_id is now the recommended way to handle it! Thanks for your PR @pavel-lexyr, and sorry for the inconvenience!