4

So I have an application that utilizes 14 different libraries. It's been a while since I have updated this application and one or more of the libraries involved have since experienced a major revision (using semantic versioning). That being said, I have just updated the application to utilize all of the newest versions of these libraries.

Additionally, one major change experienced by a library involved in the project was that an interface method name changed. The application was using that interface method so now I had to change it wherever the function was called to match the new library. That is a major change on the library most definitely, but I am thinking that this is not a major change to the application's revision.

Is my reasoning correct? What kind of a revision does the application get?

Snoop
  • 2,718
  • 5
  • 24
  • 52

2 Answers2

9

The semantic versioning rules are applied to your software from the perspective of your users. If your API has changed and is not backwards-compatible, you should update your major version number. It sounds like this isn't the case, though. It sounds like your API hasn't changed - clients who were using your previous version can simply drop in the new version without any other changes. This would be a minor version increase.

This is confirmed in the Semantic Versioning FAQ:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

Based on the comments, it appears you are using Semantic Versioning for an application. This isn't a typical use case. Semantic Versioning is designed for APIs and libraries. Another question here on Software Engineering Stack Exchange addresses the use of Semantic Versioning in applications.

In the instance of a GUI-based application, the GUI is your public interface. I would use definitions like this:

  • MAJOR version when you make changes to a user's workflow or how users interact with your software in an backwards-incompatible manner.
  • MINOR version when you add functionality in a backwards-compatible manner
  • PATCH version when you make backwards-compatible bug fixes.

If you add functionality without changing any existing workflows, it's a minor version. If you change existing workflows, it's a major version. Patch versions are bug fixes that do not change how users interact with your software.

Community
  • 1
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • When you say *your API hasn't changed* ... I would agree that the overall functionality of the API didn't change one bit for the functions that the application is using. However one function name on the interface changed, so the API did change in that respect... – Snoop Mar 31 '17 at 14:36
  • @Snoopy Did you change any of *your* public method interfaces? An API is just the interface and not the implementation. It doesn't matter if you changed the implementation. – Thomas Owens Mar 31 '17 at 14:39
  • I understand that an API is just the interface and not the implementation. Yes, I know that it doesn't matter when you change the implementation. What I am saying, is that the signature/name of one interface method changed... So that means that any client using that interface is no longer compatible, correct? – Snoop Mar 31 '17 at 14:42
  • @Snoopy You said that all you had to do was change your implementation to use the library's new method. This library had a non-compatible change. If you did not change *your* method signature, then it's compatible. – Thomas Owens Mar 31 '17 at 14:44
  • *Additionally, one major change experienced by a library involved in the project was that an interface method name changed.* I thought I was clear about saying that the method signature changed, but maybe not? – Snoop Mar 31 '17 at 14:45
  • 1
    @Snoopy You need to make the question clear. It seems like the library's interface method changed. Did *your* method signature change - the method that someone using your application would call? If it did, did *your method's interface* change in a way that is backwards compatible? The answers to those two questions determine if this is a minor or major version change. – Thomas Owens Mar 31 '17 at 14:47
  • My application is just a windows forms application, some parts changed where the method signature of the API changed. I guess, nobody would ever call a method on my application, because it's just a windows form. – Snoop Mar 31 '17 at 14:49
  • 1
    @Snoopy [This question may be relevant](http://softwareengineering.stackexchange.com/questions/255190/how-does-semantic-versioning-apply-to-programs-without-api). SemVer is typically used for APIs and libraries, not applications. However, it seems like you are building a user-facing GUI application. Your interface is the GUI. I would treat your GUI as the public interface. If your GUI changes to add functionality and no existing workflows change, then I would call that a minor. If GUI elements change such that workflows change, that is a major. But again, this is not something SemVer handles. – Thomas Owens Mar 31 '17 at 14:53
  • I mean... If somebody clicked a button, it would run a private method, but no I didn't change any method names on my windows form (application) if that's what you're saying. – Snoop Mar 31 '17 at 14:54
  • Yeah, the answer to that does say that the revision on the interface part of things is more of a marketing tool and shouldn't be handled by SemVer... Then again, the answer also considers a GUI as offering a public interface (something that SemVer *is* concerned with), which is what I am using. So that leaves me a bit confused. – Snoop Mar 31 '17 at 14:58
  • 1
    @Snoopy I've updated my answer. SemVer is only designed for APIs and libraries. You can model your versioning on it, but it's not SemVer. You can go and create a version of SemVer with written rules for user-facing applications (GUIs, command line switches, and so on). But it would be something new and unique. – Thomas Owens Mar 31 '17 at 15:00
  • Thanks for explaining that, I didn't know that SemVer was really only meant for APIs and libraries (which I have been using it for). I guess at the end of the day, the workflow for my application remains exactly the same and thus any public facing GUI interaction is also the same. So I guess I could say minor (if I continue to just use SemVer anyway). – Snoop Mar 31 '17 at 15:03
1

If you changed the public method names on a public interface in your library then yes. That is a major version change.

Why? Because users upgrading the library will have non compiling code if they used any of the old method names.

Normally the 3rd party libraries you reference in your own code are not exposed to the users of your library, so regardless of whether they have major/minor changes you would only need a point release of your code.

It was probably not a good idea to change your interface just to match the 3rd party library's naming scheme

Ewan
  • 70,664
  • 5
  • 76
  • 161