简体   繁体   中英

Semantic versioning (Breaking Changes)

In Semantic versioning, is runtime error considered a breaking change?

Say that I have a method called WelcomeToUse(string hellow) and then I change the logic on that method to a point where I have now introduced a runtime error and I am aware of that. Do I consider that scenario a breaking change?

What does the public interface of your method guarantees? How widely is your library used? I'm going to assume "runtime error" means throwing an exception.

The documentation should state if and when exceptions should be thrown, if you can keep within the document behavior you would not technically change the public API, just correcting a bug where the public API was not fulfilled.

If there is no explicit documentation then you might need to consider what a developer should expect, and how likely a new exception would be to create real problems. If your method already throws exceptions in some cases, the effect of adding another case where it throws might not have a large effect in most cases.

It would also depends on how many uses the library. For an small internal library it might just not matter that much, since there is a very limited group of people affected. On the other hand, if the library is part of windows, you might risk angering millions of users, and thousands of developers, so you might decide to keep actual bugs forever , due to the amount of software that has started to rely on said bugs.

Note that deciding if the change is a minor or major change may be less important than the decision when to make the change. If I use a library I would like it to be as stable as possible. Making overly frequent major releases that break things is almost as bad as making breaking changes in non major releases.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM