Adherence to semantic versioning with APIs
Author: mvpatel2000
Pull request: no
Labels: name: Feature request

### Feature request

Transformers is an incredibly popular library used by many folks. It would be great if Transformers would adopt semantic versioning (https://semver.org/) and follow best practices to provide API deprecations and backwards compatibility. 

For example, the following PR https://github.com/huggingface/transformers/pull/29143 breaks API changes. This is acknowledged in the PR review. In the future, it would be great to instead deprecate the existing interface and provide a new interface, and then remove the old, deprecated interface in future releases. 

### Motivation

Without following semantic versioning, users have immense amounts of pain upgrading versions and code is often broken. It also leads to hacky support such as https://github.com/mosaicml/llm-foundry/pull/1018 which now has to case on the API of multiple versions of Transformer. 

### Your contribution

N/A

Comments:
Hi @mvpatel2000, thanks for opening this feature request! 

In general, we do try and keep to semantic versioning - backwards compatibility is a big theme for the library and one which we aim to keep in mind for any feature additions or changes. 

It's true that occasionally this isn't adhered to! In the case of the linked to PR - I believe this was in part because the cache system was relatively new and being quickly iterated on, I'll let @gante and @ArthurZucker comment on that. Sometimes, we knowingly have to break things (which we try to flag in our release notes and with 🚨 in the PR title); sometimes it's accidental - and the community raising issues helps us find these :) 

There's also greater emphasis placed on continuity and lack of breaking changes for public level APIs and any objects which are importable from the top level of transformers i.e. `from transformers import x`. As the library is so large, in order to be able to fix and adapt quickly, we don't guarantee the same level of maintenance for functions, methods or classes which aren't documented in our [documentation](https://huggingface.co/docs/transformers/index). 

Hi @mvpatel2000 👋 

As @amyeroberts wrote, we aim to avoid API changes -- both in public and private classes/methods. We are aware that advanced training and inference methods rely on the manipulation of class attributes, private methods, and other non-documented properties of our library 🤗 

However, in some cases, it's very hard to add new features without breaking the existing API in the private methods. Enabling `torch.compile`, which is the underlying cause for these changes, is one of these features. Arguably, we could have created new classes to handle it, but we would not have the bandwidth to maintain both groups of classes. When faced with a choice to break a few cases on undocumented parts of our library and add a powerful feature, or focus on stability, we tend to prefer the former -- it may have an associated growth pain, but I believe we can agree that it is beneficial for everyone in the long run.

I apologize for any friction on your side, and I promise we will keep changes at an undocumented level down to a minimum. Please open issues with us when something breaks on your end, as we are not fully aware of all cases of [Hyrum's law](https://www.hyrumslaw.com/) :)