How to do Semantic Versioning (Semver) with GIT?

Asked

Viewed 790 times

3

One question that I’ve always had and gives me a lot of headache is about how I should do Semantic Versioning with GIT.

I should take into consideration the commit, one "release" of the project, or something else?

Release

Example of a history of commit’s with the type of change taking into account that the version number is defined in a release.

v2.1.4 - Release 04

(The release had 1 major, 1 minor and 4 patches)

  • Patch
  • Major
  • Patch
  • Patch
  • Minor
  • Patch

v1.3.4 - Release 03

(The release had 2 Minors and 4 patches)

  • Patch
  • Patch
  • Minor
  • Patch
  • Patch
  • Patch
  • Minor

v1.1.5 - Release 02

(The release had 1 minor and 5 patches)

  • Patch
  • Patch
  • Minor
  • Patch
  • Patch
  • Patch

v1.0.3 - Release 01

(The release had 3 patches)

  • Patch
  • Patch
  • Patch

Commit

Example of a history of commit’s with the type of change taking into account that the version number is defined as soon as a commit is made.

v2.0.1 - Release 04

  • Patch (2.0.1)
  • Major (2.0.0)
  • Patch (1.4.2)
  • Patch (1.4.1)
  • Minor (1.4.0)
  • Patch (1.3.2)

v1.3.1 - Release 03

  • Patch (1.3.1)
  • Minor (1.3.0)
  • Patch (1.2.3)
  • Patch (1.2.2)
  • Patch (1.2.1)
  • Minor (1.2.0)

v1.1.2 - Release 02

  • Patch (1.1.2)
  • Patch (1.1.1)
  • Minor (1.1.0)
  • Patch (1.0.6)
  • Patch (1.0.5)
  • Patch (1.0.4)

v1.0.3 - Release 01

  • Patch (1.0.3)
  • Patch (1.0.2)
  • Patch (1.0.1)

You can see that they had different versions:

inserir a descrição da imagem aqui

With the specification to say what would be the way to do it? (Even if not these) or is it something the team decides on and has nothing to say?

git commit release semver

  • You need to know what type of release (therefore, release) is doing to know at what point the M.m.i you will increment. It makes no sense to close a version without closing. And, depending on what you entered, you need to climb one or the other number

  • But the way I’m doing in the example of release is correct?

  • 1

    I would say no. Each version for me would be one release different. I would not join several versions in a release. It only makes sense that you upload the version when there is release, then say that a release consists of 6 versions I see as an offense to semantic versioning worse than cursing the mother. You may have several types of correction in a release, but that would only imply raising one of the numbers in the M.m.i and zero the least significant numbers

  • @Jeffersonquesado I believe I understand, I feel more relaxed now. Just to confirm, let’s say that the app is in the version 1.4.3 and in it I made several fixes (patch) and incompatible changes in the API (major), then the release would be version 2.0.0?

  • 1

    that’s right. I later check if you already have an adequate answer and, if not, write a

  • 2

    Yes, the specification itself defines: "Once a versioned package has been released (Released), the contents of this version MUST NOT BE modified. Any modification MUST be released as a new version" or MAJOR 1.x.x I could only go to the Major 2.x.x. https://semver.org/lang/pt-BR/#spec-item-3

  • And the way I see it, you don’t define the commit-based version. Creating, for example, a change from version 1.x to 2.0 would probably be too big a change to just one commit. The ideal is to commit under necessity and define versions with tags.

  • @Viníciuslima, I believe it’s a duplicate of this one, but I’m not sure: https://answall.com/q/51817/64969

  • @Jeffersonquesado This help, but it’s not exactly the doubt of the question that was really about using GIT, which I should take into consideration to define the version that in case I gave the example of release and commits that they were both incorrect. But you have already cleared the doubt in the comments on 3° comment on the question to be more exact. "I would say no. Each version for me would be a different release, etc..."

Show 4 more comments

1 answer

3

all right?

I will be doing a short summary based on some articles and contents about "Semantic Version".

0.0.1
Patch:
- Used to inform "hot-fixes" and they do not change the functionality of the code, but solve "bugs".

Observing: It is always increased by a unit and has no limits in its application.
Example: 0.1.30


0.1.0
Minor:
- Used to represent new functionalities (Features) in the project.


Observing: When incremented reset all previous "patch" units or resulting in a new functionality without "bugs" so far.
Also increments by one unit.
Example: 0.0.15 --> 0.1.0


1.0.0
Major:
- Represents an incompatible version or some drastic change in the project.

Observing: Increment by one unit and when updated, reset versions of "minor" and "patch".
Example: A library uses Stancias for its use and in its next version uses export named to use its functionalities. Therefore, the previous form of its use is incompatible. 0.5.10 --> 1.0.0



Bibliography:
The Successful Git branching model
A Quick intro to Semantic Versioning: what it is, and Why we use it
What is Semantic Versioning?


I hope I’ve helped you!

Browser other questions tagged git commit release semver

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