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
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.