Software Versions are Broken

Două lucruri:

Instead of Major.Minor.Patch, think Breaking.Feature.Fix.

&

The numbered version is there so npm and developers can tell whether or not a new version is a breaking change, an added feature, or a bug / security fix.

4 Likes

In comunitatea node, s-a discutat destul de aprins prin 2013 despre semver, ca si conventie s-a ajuns la:

Major: “breaking changes”

Increment MAJOR version when you have removed or changed a feature, and dependent modules will have to modified to be compatible with the new version.

Minor: “new feature”

Increment MINOR version when you have added a feature, but the module is backwards compatible.

Patch: “bugfix”

Increment PATCH version when you have fixed a problem, but not broken or changed anything else.

Un topic unde se discuta urmatoarea idee:

the first version I commit to source control is 1.0.0-pre, and the first version I publish to npm is 1.0.0. If it’s not stable enough to get 1.0.0, it doesn’t deserve to be published to npm; if it’s published to npm, any consumers deserve to get the benefits of bugfixes instead of being forced to stick to an exact version like they would if I published it as 0.x.

Tipul/tipa continua sa spuna:

If it’s time to write a blog post to inform the community about new features or important changes, find the version you want to publicize, tag it “latest”, and give it a human-readable name (e.g., “MVP”, “Aardvark”, etc…).

That human readable release name does not replace SemVer. “MVP” might correspond to v1.6.23 or v2.2.5 — the point is, the numbered version has nothing to do with the named release.

Release.Breaking.Feature.Fix

Intrebarea mea este: De ce sa nu folosim patru numere? Release.Breaking.Feature.Fix? Ar rezolva multe din problemele inca existente, precum nevoia de a numi fiecare release folosind nume ciudate gen BraveYard, SwagMinator, PowderJuice, LiquidMagenta sau FlyingRacoon.

De ce am folosi acea notatie?

Fiindca, pe langa problema cu numele asociate diferitelor versiuni, diferite release-uri pot sa continue sa primeasca suport, astfel evitam situatii de genul Firefox sarind de la versiunea 5 la 42 in doar cativa ani, precum si urmatorul exemplu:

  • Windows 7 release = v32.69.45
  • Windows 8 release = v33.62.71
  • Windows 7 Service Pack 1 = v34.12.96 ???

In schimb, am avea ceva de genul:

  • Windows 7 release = v17.12.36.12
  • Windows 8 release = v18.3.16.9
  • Windows 7 Service Pack 1 = v17.16.2.39

Iar Release-urile ar trebui sa fie ceva de genul acesta:

(poza preluata din articolul in cauza)

Edit: Am mai batut campii putin aici: Release.Breaking.Feature.Fix or why the Semantic Version should be replaced with Explicit Versioning as soon as possible.

2 Likes