How to version front-end projects?

Question

Semantic versioning brings the follow approach:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backwards-compatible manner
• PATCH version when you make backwards-compatible bug fixes

However a frontend project doesn't have an API, its doesn't break compatibility of usage, then, what the arguments to change the versions in frontends?

Please, sugestions.

Answer 1

Proposal

Given the importance of the installation-requirements of an application to installer-users, I propose that semver be used to version end-user applications using the installation-requirements as the public API with installer-users as the consumers of this API. In practice, increment the:

• MAJOR version when you make incompatible API changes (e.g. installer-users have to modify their infrastructure (phone/tablet/PC/web-server/firewall config/etc) in some way),

• MINOR version when you add functionality in a backwards-compatible manner (e.g. passing additional data to an already-provisioned API or adding any end-user functionality that does not affect the installation-requirements), and

• PATCH version when you make backwards-compatible bug fixes (e.g. fixing any end-user bug that does not affect the installation requirements).

By treating the installer-users as the consumers of an end-user application, and the installation-requirements as the public API, I believe that semver does make sense and is valuable as a communications mechanism for end-user applications.

https://medium.com/@u_glow/making-sense-of-semantic-versioning-for-end-user-software-applications-a3049d97478b