Petr Schreiber
28-07-2018, 19:10
Dear Eros, dear community,
I would like to share one concept for software development, which I find easy to follow both for developers and their users.
It could be applied to thinBASIC, it could be applied to thinBASIC modules, it could be applied to applications you develop with thin tools.
Semantic versioning
Semantic versioning is often mentioned as "created by" Tom Preston-Werner. He indeed deserves the credit for keeping all the rules on one place, the system is basically a composition of common sense rules.
It can be read in its whole here: https://semver.org/
The approach gained significance for languages with package system, but I find it highly valuable even for other types of applications.
In a nutshell, version is considered a set of 3 numbers:
MAJOR.MINOR.PATCH
Changing the major should be done only in case you introduce backwards incompatible changes.
Changing the minor should be done in case you add new feature.
Changing the patch should be done in case the new version introduces some fixes.
I also like the "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."
This also somehow implicates it is good idea to do pure bugfix, pure feature releases, which is a concept I like.
The benefits
The main benefit I see is the clear communication towards user:
- if you are using software / module in version A.0.0, it is guaranteed the use will be the same with any A.*.* version (because A guarantees backwards compatiblity). However, you know you should be alerted once version B.*.* appears and you should not migrate without proper thought
- if you expect certain feature from software / module, specifying version on MAJOR.MINOR level is completely sufficient
- if you see version MAJOR.MINOR.1 and MAJOR.MINOR.2, no reason to think if I should pick first or second, the MAJOR.MINOR.2 should be of more quality (less bugs) than MAJOR.MINOR.1
How could thinBASIC gain from this?
ThinBASIC already offers handy #minVersion statement, which restricts the execution of script by older version of interpreter.
It would be interesting to have something similar for thinBasic modules - very useful for 3rd party development, modules not in the standard distribution.
Such mechanism could prevent mis-use of module with wrong version of core for example.
Being agreed on the semantic versioning approach could also mean we could introduce some further dependency checks and restrictions, which could increase stability of the tools we use and develop.
Petr
I would like to share one concept for software development, which I find easy to follow both for developers and their users.
It could be applied to thinBASIC, it could be applied to thinBASIC modules, it could be applied to applications you develop with thin tools.
Semantic versioning
Semantic versioning is often mentioned as "created by" Tom Preston-Werner. He indeed deserves the credit for keeping all the rules on one place, the system is basically a composition of common sense rules.
It can be read in its whole here: https://semver.org/
The approach gained significance for languages with package system, but I find it highly valuable even for other types of applications.
In a nutshell, version is considered a set of 3 numbers:
MAJOR.MINOR.PATCH
Changing the major should be done only in case you introduce backwards incompatible changes.
Changing the minor should be done in case you add new feature.
Changing the patch should be done in case the new version introduces some fixes.
I also like the "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."
This also somehow implicates it is good idea to do pure bugfix, pure feature releases, which is a concept I like.
The benefits
The main benefit I see is the clear communication towards user:
- if you are using software / module in version A.0.0, it is guaranteed the use will be the same with any A.*.* version (because A guarantees backwards compatiblity). However, you know you should be alerted once version B.*.* appears and you should not migrate without proper thought
- if you expect certain feature from software / module, specifying version on MAJOR.MINOR level is completely sufficient
- if you see version MAJOR.MINOR.1 and MAJOR.MINOR.2, no reason to think if I should pick first or second, the MAJOR.MINOR.2 should be of more quality (less bugs) than MAJOR.MINOR.1
How could thinBASIC gain from this?
ThinBASIC already offers handy #minVersion statement, which restricts the execution of script by older version of interpreter.
It would be interesting to have something similar for thinBasic modules - very useful for 3rd party development, modules not in the standard distribution.
Such mechanism could prevent mis-use of module with wrong version of core for example.
Being agreed on the semantic versioning approach could also mean we could introduce some further dependency checks and restrictions, which could increase stability of the tools we use and develop.
Petr