How to view front-end projects?

Asked

Viewed 260 times

5

How to view front-end projects?

Semantic versioning brings the following approaches:

  • MAJOR - when you make incompatible API changes
  • MINOR - when you add functionality compatible with previous versions
  • PATCH - when making bug fixes compatible with previous versions. Additional pre-release labels and build metadata are available as extensions to the MAJOR.MINOR.PATCH PATCH format.

But a frontend artifact does not have Apis, so they do not break compatibilities with those who use them.

How it would be better to increase the numbers of front-end versions?

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

I would like suggestions.

front-end versioning

  • What do you consider "a frontend artifact"? give some examples if possible.

  • Here I am referring to the frontend project, in case everything that is within the source repository.

2 answers

2

Semantic versioning brings the following approaches: [...] but a frontend artifact does not have Apis, making them not break compatibility with those who use them.

Exact. Semantic versioning is used to normalise the behaviour of dependencies. An end consumer is not a dependency, so the model does not apply - however several companies perform married implementations, keeping the UI versioning in lockstep with the version of the consumed API.

How it would be better to increase the numbers of 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, it would be a change of type MAJOR?

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 of the version 1 API.

  • I opened the question aiming to collect suggestions of how to Versionar, the projects where I act do not necessarily match only one API, if it is Microservices a frontend can use Apis from several different backends, so it does not make sense to launch married versions, that in my view does not make much sense at other times also.

1

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

Given the importance of application installation requirements for installers, I propose that Semver be used for end-version applications using the installation requirements as a public API with installers as consumers of this API. In practice, step up:

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

Browser other questions tagged front-end versioning

You are not signed in. Login or sign up in order to post.