Another interesting point is that the "public contract",...

Another interesting point is that the "public contract", or API surface, of the project should not be broken unless the change is universally considered to be the right thing to do:

https://rfc.zeromq.org/spec/42/#26-evolution-of-public-contracts

This means that the project *should* be free to ship new releases regularly and users can upgrade without concern for behavior or API breaking changes.

The solution is to use new names for the changed "contracts" without changing the existing contracts. Not easy to do, but possible!

Like 17 May 2023 at 7:43 | Open on fosstodon.org

2 comments

Christian Tietze

@daviwil ... but also not that hard to do, either! In terms of programming API, leave old function signatures untouched (or append parameters with default values, or overloads with more parameters), for example. That's more or less standard practice, no?

17 May 2023 at 9:13 | Open on mastodon.social

David Wilson

@ctietze Depends on the language, some tolerate parameter and field additions better than others.

Depending on the type of change, might be better to just make a new function entirely and then change the existing function to just be a wrapper for the new function (or functions, if the behavior is getting chopped into smaller pieces).

Definitely possible to do this, just requires a bit more discipline to not break the existing stuff in unexpected ways!

17 May 2023 at 9:17 | Open on fosstodon.org