#Simple Versioning 0.1
Semantic Versioning is great, but it can be overkill for small standalone projects. Projects that have no dependencies on specific versions of other projects do not require a sophisticated method of software versioning.
Keeping software versioning simple allows teams to focus on building their products; rather than the version number they should be using across the development lifecycle.
Given a version number MAJOR.MINOR, increment the:
- MAJOR version when you make major release builds,
- MINOR version when when you make changes during pre release development, testing and QC
No letters are used.
-
The first version of a project is: 0.1. The number to the right of the decimal point increase after every iteration of development, testing and quality assurance. Iterations can be defined by the team. There is no ceiling to the number (e.g version 0.87 is fine)
-
The first major release of a project is: 1.0. The first major release is defined as when a product has passed QC and is first delivered to the client (or put in production).
-
Modifications to the first major release obey the versioning from point 1). For example, some bug fixing after the first release may create versions 1.1, 1.2 and 1.3.
-
You only create version 2.0 (and subsecquent major releases), for significant modifications to your build (e.g A lot of new functionality added to your project).
0.1 The first build of a new module, not necessarily sent for QC as this may only be for SCORM Cloud / feature testing. Depending on what is being checked, this may only be a partially complete module.
0.2 More developer testing.
0.3 Sent for producer review.
0.4 Sent to QC for testing.
0.5 Includes bug fixes from QC.
1.0 QC signed off and ready to send to the client.
1.1 Some bug fixes are picked up in the first major release
2.0 Another topic is added to the module