Semantic Versioning

1 - Respect House Rules

When working on an existing software development, it is best to seek out their documentation related to its release strategy, processes and version tag procedures. These are known as standards of procedures (SOP).

It they do exist, comply to the house rules.

Rationale

1. Backward-compatible at ecosystem level - don't create shock to the existing communities
2. Respect - you wouldn't want a visitor to walk into your house and start ruining it, wouldn't you? Karma holds so respect the house rules.

2 - Comply to Git Semantic Versioning System

If there is no semantic versioning SOP available, then I will default to the git semantic versioning system, the one with the 'v'. Example:

v0.1.0

v0.125.3

v1.0.0

v1.25.0

The pattern is:

v[major].[minor].[patch]

Where:

1. major number indicates **backward incompatible** changes, possibly breaking things.
2. minor number indicates **backward compatible** changes, an update to the previous version.
3. patch number indicates **small changes** like bug fixes, security releases or documentation updates.
4. The major number 0.X.X indicates project is still under development, hence, any crazy things may happen in between.

Rationale

1. less learning curve = fast integration - don't need to purposely learn a tag system. It's intuitively understood.
2. simple and standardized - complies to both git and semantic versioning standards means less headaches over customization.

That's all about my discipline for semantic versioning and tagging discipline.