How to version front-end projects?

  

Semantic versioning has the following approaches: [...] however, a frontend artifact has no APIs, so they do not break compatibility with those who use them.

Exactly. Semantic versioning is used to normalize the behavior of dependencies . A final consumer is not a dependency, so the model does not apply - though many companies do married implementations, keeping the UI versioning in lockstep with the version of the API consumed.

  

In what way would it be best to increment the numbers of the versions of a frontend?

If they occur at the same time, use the same API version tag. If not, it is up to you to create (or reuse) a versioning criteria definition.

  

If my frontend were to consume a new third-party API, would it be a MAJOR type change?

It is at the discretion of the project, since SV does not apply. Version 2 of an app may well be using the same endpoints as the version 1 API.

I found a nice article that suggests some rules for versioning frontends, the article basically says the following:

Given the importance of installing application requirements for installers, I propose that Semver be used for final-version applications using the installation requirements as a public API with installer users as consumers of this API. In practice, increase:

• MAJOR when you make incompatible API changes (for example, installer users must modify their infrastructure (phone / tablet / PC / web-server / firewall config / etc)
• MINOR when you add functionality backward compatible (for example, passing additional data to an already provisioned API or adding any end-user functionality that does not affect the installation requirements)
• PATCH when you make bug fixes backward compatible (for example, fixing any end-user errors that do not affect the installation requirements).