| Current Path : /proc/thread-self/root/home/jstimm/Desktop/50_dev2017/1313__procpyjs/doc/DevPlatform/ |
Linux ift1.ift-informatik.de 5.4.0-216-generic #236-Ubuntu SMP Fri Apr 11 19:53:21 UTC 2025 x86_64 |
| Current File : //proc/thread-self/root/home/jstimm/Desktop/50_dev2017/1313__procpyjs/doc/DevPlatform/Versioning.md |
#Versioning at IfT DevOPs Team We are using *semantic versioning* for our projects. Semantic versioning is a standard that a lot of projects use to communicate what kinds of changes are in a release. It's important to communicate this, because sometimes those changes will break the code that depends on the package. ##Semantic Versioning If a project is going to be shared with others, it should start at **1.0.0**. After this, changes should be handled as follows: - Bug fixes and other minor changes: *Patch release*, increment the last number, e.g. 1.0.1 - New features which don't break existing features: *Minor release*, increment the middle number, e.g. 1.1.0 - Changes which break backwards compatibility: *Majore release*, increment the first number, e.g. 2.0.0 ## Semantic Versioning as a Consumer Now this might sound all a little bit to complicated for doing versions, there is a catch. At the DevOPs team we use heavily *npm*. Using npm and the knowledge about semantic versioning, we can specify which kinds of updates our app can accept in the *package.json* file. If you were starting with a package, say 1.0.4, this is how you would specify ranges: - Patch releases: 1.0 or 1.0.x or ~1.0.4 - Minor releases: 1 or 1.x or ^1.0.4 - Major releases: * or x ## Is there help? Yes. There is. We've developed a commandline tool called **fast-release**. With it, you can easily handle the semantic versioning of your package and it does all the updating and pushing to remote repositories automatically for you. Please feel free to get support using the fast-release utility.