Suggestion: Bump the major release number when releasing a compatibility-breaking version

[lstein]

The InvokeAI team had a bit of a surprise yesterday when diffusers moved from 0.14 to 0.15 and changed the names of several documented methods that we were using. Because we had pinned diffusers using the "compatible release" indicator (diffusers ~= 0.14) we did not expect to get an upstream update to an incompatible version. Unfortunately this caused more than a handful of new user installs and updates to crash in an unsightly way until we released a hotfix today.

Would you consider moving to a semantic numbering scheme before the next compatibility-breaking release? At this point, we've learned our lesson and are using == to pin the exact version, but it would be nice to be able to take advantage of incremental improvements and bugfixes without worrying about a repeat of what happened with 0.15.

[patrickvonplaten]

Hey @lstein,

I'm sorry that updating diffusers to 0.15.0 led to many breaking changes.

Note that we are fully commited to introduce no breaking changes when making releases.

Could you maybe provide some more details of what broke exactly?

We consider any change to the public API which includes all objects, its public functions and all methods that are directly importable from the main init such as:

from diffusers import ...

a breaking change. Note that we consider methods that have a leading _ not public API and we also don't consider methods and objects of subfiles such as:

from diffusers.pipelines.stable_diffusion import ...

public API

[patrickvonplaten]

It would be great if you could add some examples of what broke with the release so that we can make a patch release

[patrickvonplaten]

Also @pcuenca @sayakpaul here this shouldn't have happened as it's the core promise of diffusers.
Would love to.investigate what went wrong

[sayakpaul]

@patrickvonplaten related comment:
#2849 (comment)

[patrickvonplaten]

Patch release is out: https://github.com/huggingface/diffusers/releases/tag/v0.15.1

In summary I think it was a mixture of us not being careful enough in #2849 and lots of accessing of non-public methods from outdated files. I'll try to allocate some time this week to go through InvokeAI codebase to see if we can make diffusers<>InvokeAI more robust.

[github-actions]

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 are likely to be ignored.