Classification of smart contract changes

[PaulRBerg]

I propose the following classification for smart contract changes:

Name	Description
Non-Breaking Change	Adding functionality + updates that don't change the public API
Soft Breaking Change	Updates that affect only stream or airdrop creation
Hard Breaking Change	Updates that affect existing streams OR change the public API

Updating only the stream or airdrop creation functionality doesn't increase the complexity in the UI app/ subgraphs because there is no need to maintain backward compatibility (if/else logic for older versions). The UI would just use the most up-to-date API.

FYI @sablier-labs/engineers

[andreivladbrg]

Good list! I think it’s a great idea to include these in the GitHub labels as well:

wdyt?

[PaulRBerg]

Thanks!

I wouldn't rush with GitHub labels just yet. These classifications are not relevant for every task.

Let's also wait to receive more feedback on this.

[andreivladbrg]

re the description of “Hard Breaking Change,” should we also include “ + updates that change the public API”?

[PaulRBerg]

Yes. Good point.