startup versioning: All our software starts in version 3 , else everyone will think we are stagnant or have no product, followed by a large subverison like 37 to show the world we are working hard and a patch version like 3 to show we don't have any bug, so our software is 3.37.3 beta , beta because we need to show the world we are on the bleeding edge of course we don't make multiple versions of the same products, all software starts on version 3.37.3 beta and when we need to make the slightest change on how it works, we create a new software with a different name in a new javascript framework using the lastest blockchain technology
Windows is using semantic versioning, and the number now appended to the name "Windows" is just the major version. You can find the minor version and patch numbers through various ways, such as the dialog box that you get when you click on the "About Windows" menu item in the Help menu of Windows Explorer. Windows version 4 went out as Windows 95, 98, and Me; Windows 5 was marketed as Windows XP; and Windows 6 was sold as Windows Vista. Major version 9 got skipped because Microsoft found that too many programs check which version of Windows they are running on by checking if the major version number starts with the digit 9 to assume that they must therefore be running on Windows 95 or Windows 98, meaning that Windows 9 would essentially be cursed with confusing too many third-party programs into thinking that they are running on a super-old Windows OS, which would cause a lot of problems leading people to complain both about those programs and about Windows somehow being defective because of too many programs breaking when running on it.
I have to admit: I always thought that the '4.2' in SUSE's initial release was meant to be read '4.2.0', and that it was a reference to something altogether different. Well, you never stop learning, I guess. In my defense, their preferred color scheme has always been green :)
Really clean explanation of versioning strategies, especially semantic versioning and minor release.patch numbers reset. Semantic versioning always made sense to me. It would be good maybe to talk in another video, how to combine versioning and CI/CD process in an automated way, like append build numbers after patch etc. One more topic of versioning is specifically REST API versioning strategies, which are a bit different and probably were out of scope for this vid. Also applying semantic versioning rules, terraform is still not GA although it is widely used everywhere ;p
@@DevOpsToolkit Yes please! Would be good to have a look at semver modifiers, which are useful in CI workflows. We have C++ builds (with Conan) which create a constant stream of artefacts pushed to Artifactory and it is important to have those ephemeral versions followed up and bundled correctly in the test deployments. So the natural way is to use the commit hashes for the modifiers, like vX.Y.Z-#commit. Problems multiply when the artifacts are combined from several repos and several commits :-( Jenkins job IDs are also used for the purpose...
Honestly it's the first time I have heard the term SemVer and CalVer . Thanks a lot for your videos 🙂 . Video request : How about a video on Podman (Podman vs Docker) . Thank you
@@DevOpsToolkit please also review it within the Skaffold context! Strangely Podman is not included as a separate Builder. Is it because podman build can emulate docker build exactly? What if one wants explicitly to use both for whatever reason?
I use a combination of semantic and calendar versioning. 1.2.3-20210523. Each will work for it self, but I like to see braking changes and like to know how old the version is.
It's normal and quite common to add a suffix to semantic versions. I do that all the time, sometimes with CalVer as a suffix, and, at others, with commit hashes.
Cal-ver can be used when there are multiple repositories holding SQL scripts that are executed against the same DB schema. If they can be ordered by calendar or timestamp it would have not be necessary to orchestrate which one should be executed when.
@@DevOpsToolkit it should, but if the same DB scheme is evolved from more than one source, imagine a product and customization plugins, that are naturally chronologically dependent than CalVer becomes handy
@@borispavlovic1973 You are absolutely right. If you do need to manage a single schema of a single DB from definitions split into multiple projects/repos then being able to order releases is very helpful. That makes CalVer a good choice.
There are other considerations. Semantic versioning is more important for publicly facing software versus, for instance a micro-service that is deployed to production with high frequency. You also need to consider if the artifact needs to be compatible with package management, such as YUM/DNF. I also don't think including the Git short hash is entirely silly. I have included it in versions for internal micro-services that deploy frequently to end the conversation about, "how do I go back to the deployed service's source code." In practice no one ever really needs to do this but also, in practice, people do all sorts of nasty things in their SCM to support this that are entirely unnecessary if the hash is present in the artifact's version.
I agree. SemVer natters mostly to technical users using an application. If, as you mentioned, it is a microservice, using build numbers or commit hashes is just as good and easier to do. Still, if that microservice is a dependency of apps developed by other teams, then those other teams are technical users of it and they might benefit from SemVer. For example, they might make decisions whether to use a newer version of the API of that microservice depending on whether it is a major or a minor change.
My question is if its a breaking change and needs to supply a major version. How the code base allowed if the change is breaking change. Breaking changes will not be allowed into the code base right. Otherwise, am I understanding differently..
Breaking changes are allowed when there is no other option, hence they are made rarely, if ever. When a breaking change is introduced, a "special" process and care is required to roll it out. As an example, kubernetes is 10 years old now and it is still major version 1. It did not introduce a breaking change, at least not intentionally, even once. Most of it's controllers are also version 1.
Git hash as I have a CI/CD pipeline and I deliver SaaS. If I have to patch something i just branch from that hash, fix, then merge back. Team can always check the git in order to understand the changes. Semver was flawed in my case as the rate of changes coupled with feature toggles made it confusing.
Oh yeah. If you are delivering SaaS, your users do not need to know release versions and, in those cases, SemVer is not relevant as long as other teams in your company do not consume that through the API.
@@DevOpsToolkit SemVer in my oppinion is perfect for versioning contracts not implementations. 1.0.0 could hide hundreds of refactorings that are irrelevant to the outside world.
@@saigajester That's correct. That's why normally we use patches (changes that do not bring new features and are backwards compatible). Nevertheless, if a service is only consumed by the outside world and only by humans, than semver is not relevant. That being said, that is rarely the case unless there is only one big monolith (if no other services communicate with it).
I would not throw git commit shas with build numbers in one pot. While build number varies with each run of some job, the git commit sha gives you the exact git ref which is deployed. But that is only value able for the active developer on a particular service, nothing for users and/or marketing. SemVer is great because it is well documented and has a good acceptance. But just becomes a pain with high frequent releases.
You're right. I shouldn't put build numbers and Git SHAs into the same bucket. SHAs are much more informative and have bigger value than build numbers. We could get to the SHA through a build number but only for a short while since builds eventually get deleted while SHAs are forever. Now, I would not say that SemVer is a pain. Or, to more precise, they are not a pain if they are auto-generated through pipelines. Patch numbers are normally generated without any intervention while for the major and minor versions we would typically add a label to a PR so that the system can know to increment those. That is indeed an extra step but it's one that I feel we should be doing even without using SemVer. There should be an indication in the PR that it is a new feature and not only a bug fix.
Alphas and betas do not count. They are early releases meant to be used only for testing and are almost certain to be changed or deprecated before they reach stable versions. They should not be used in production. On top of that, those are separate things. There is Kubernetes itself, and then there are custom resources, ingress being one of them. Those two have separate lives and are versioned separately. Think of it as, for example Jenkins (core) and Jenkins plugins. Former is equivalent to Kubernetes and the latter to CRDs (e.g. Ingress, Deployment, StatefulSet, etc.).
Hi thanks for the video.. i have one problm like when i am running on my feature branch the Tag version is 1.0.1, whn merging with the Develop Branch its getting changed to 271.1.0,but i want to be with 1.0.1 version for the Client SDK and the Data N Service Dll... but why its getting changed? any idea
I'm not sure I understand the question. When you merge one branch into another, both are combined. Are you saying that the branch you're merging into does NOT contain 271.1.0 yet that's what you're getting?
@@DevOpsToolkit My git version file has CD version with 1.0.1, so i am working on my feature branch and merging with Develop then the version of Nuget shloud be 1.0.1 but its coming with 271.1.0. Actually it shld be 1.0.1. based on my Gitversion file. Why its getting changed i am not able to understand
So using Kubernetes as an example, when in version 1.16.0 they removed support for some APIs in Kubernetes like "extensions/v1beta1" or "apps/v1beta2" for the Deployment Resource, shouldn't this version be a major release?
I would say "no" since beta and alpha versions are not supposed to be used (even though we all used them). They are for testing purposes only. If we would translate that to apps developed as closed source, those versions would probably never go public. But, since it's OSS, it is public and can be used by anyone. Still, they are temporary and not officially supported. If k8s changes or deprecated v1 of its resources, then it should be v2.0.0.
@@DevOpsToolkit Good point. Thanks! About this topic, I would like to know more about automating this versioning process. Particularly in a situation when you may have different services, that alone are relevant and do something independently and so they have their own version, but are also part of a bigger product with a bunch of services.
@@andrepires5251 The situation you're describing is similar to Kubernetes. As a whole, it is v1.20.1. However, each of the resources (conceptually similar to microservices), are specific versions (e.g., Deployment v1, v2beta1, etc.). What I'm trying to say is that you can and should version is a deployable unit (a microservice) but also a whole package. As for automation of the versioning process... If you're using GitHub, you can adopt one of many tools that help with that (many are available as GitHub Actions as well). Most of the time, the idea is to find the latest tag, and increment the patch version by one, unless the PR has a label. If there is a label `minor` or `major` (or something similar), then the process would increment a different number and reset all those to the right. Like that, whoever creates a PR can decide whether it is an increment of the major or minor version, and if no decision is made, it'll increment the patch number. I'll add it to my TODO list to create material about it through a practical demo.
From the GitOps perspective, release versions are not that important. What matter is that you update manifest and that is in most cases limited to image tags (which are often the same as release versions).
How do you version your releases?
startup versioning: All our software starts in version 3 , else everyone will think we are stagnant or have no product, followed by a large subverison like 37 to show the world we are working hard and a patch version like 3 to show we don't have any bug, so our software is 3.37.3 beta , beta because we need to show the world we are on the bleeding edge
of course we don't make multiple versions of the same products, all software starts on version 3.37.3 beta and when we need to make the slightest change on how it works, we create a new software with a different name in a new javascript framework using the lastest blockchain technology
Unfortunately, I worked in a couple of places that do exactly that.
Brooo thank you for finally driving the point home. Semantic versioning sounds like the way to go. I now feel ready to pass a test on SemVer
Thanks for this video. We have very few knowledge bites on Semantic versioning. Glad you contributed in this space. 👍
Thank you for explaining this. This really helps! Thank you so much!
Thanks, Victor!
I've always used semantic versioning.
Thanks for shedding some light on the other available forms of versioning!
Windows is using semantic versioning, and the number now appended to the name "Windows" is just the major version. You can find the minor version and patch numbers through various ways, such as the dialog box that you get when you click on the "About Windows" menu item in the Help menu of Windows Explorer. Windows version 4 went out as Windows 95, 98, and Me; Windows 5 was marketed as Windows XP; and Windows 6 was sold as Windows Vista. Major version 9 got skipped because Microsoft found that too many programs check which version of Windows they are running on by checking if the major version number starts with the digit 9 to assume that they must therefore be running on Windows 95 or Windows 98, meaning that Windows 9 would essentially be cursed with confusing too many third-party programs into thinking that they are running on a super-old Windows OS, which would cause a lot of problems leading people to complain both about those programs and about Windows somehow being defective because of too many programs breaking when running on it.
Great video about Software Versioning
I have to admit: I always thought that the '4.2' in SUSE's initial release was meant to be read '4.2.0', and that it was a reference to something altogether different. Well, you never stop learning, I guess. In my defense, their preferred color scheme has always been green :)
Really clean explanation of versioning strategies, especially semantic versioning and minor release.patch numbers reset. Semantic versioning always made sense to me. It would be good maybe to talk in another video, how to combine versioning and CI/CD process in an automated way, like append build numbers after patch etc. One more topic of versioning is specifically REST API versioning strategies, which are a bit different and probably were out of scope for this vid. Also applying semantic versioning rules, terraform is still not GA although it is widely used everywhere ;p
Adding both to my TODO list...
@@DevOpsToolkit Yes please! Would be good to have a look at semver modifiers, which are useful in CI workflows. We have C++ builds (with Conan) which create a constant stream of artefacts pushed to Artifactory and it is important to have those ephemeral versions followed up and bundled correctly in the test deployments. So the natural way is to use the commit hashes for the modifiers, like vX.Y.Z-#commit. Problems multiply when the artifacts are combined from several repos and several commits :-( Jenkins job IDs are also used for the purpose...
Thank you!! So few videos about this topic
Please make video about project structure, monorepo vs multirepo, where to store infra code: near software code or in another repo etc.
Just published a video about monorepo: ruclips.net/video/VvcJGjjEyKo/видео.html
Thanks! After you it looks so obviously )
Honestly it's the first time I have heard the term SemVer and CalVer . Thanks a lot for your videos 🙂 .
Video request : How about a video on Podman (Podman vs Docker) .
Thank you
Added Podman to the TODO list... :)
@@DevOpsToolkit please also review it within the Skaffold context! Strangely Podman is not included as a separate Builder. Is it because podman build can emulate docker build exactly? What if one wants explicitly to use both for whatever reason?
@@andreykaliazin4852 I might have a better alternative to Skaffold published next week :)
Thanks for your video, learned a lot about versioning
Appreciate these videos as a non-dev that likes learning about development. Also wonder what fighting games your using that fighting-stick pair for.
That one contains a couple of thousand arcade games. The last one I played was Wonder Boy :)
Amazing content, thanks 🤟🏻
Really helpful. Thanks a lot
I use a combination of semantic and calendar versioning. 1.2.3-20210523.
Each will work for it self, but I like to see braking changes and like to know how old the version is.
It's normal and quite common to add a suffix to semantic versions. I do that all the time, sometimes with CalVer as a suffix, and, at others, with commit hashes.
awesome thanks!
Versioning Schemas:
1 - Build Number Versioning
2 - Commit Hash /Git Short Hash, Git Commit Hash/ Versioning
3 - Calendar /CalVer/ Versioning
4 - Semantic /SemVer/ Versioning
5 - Random /System Native/ Versioning
6 - Milestones /Marketing/ Versioning
7 - Geeky /Silly/ Versioning
Cal-ver can be used when there are multiple repositories holding SQL scripts that are executed against the same DB schema. If they can be ordered by calendar or timestamp it would have not be necessary to orchestrate which one should be executed when.
Shouldn't that be managed by something like Flyway?
@@DevOpsToolkit it should, but if the same DB scheme is evolved from more than one source, imagine a product and customization plugins, that are naturally chronologically dependent than CalVer becomes handy
@@borispavlovic1973 You are absolutely right. If you do need to manage a single schema of a single DB from definitions split into multiple projects/repos then being able to order releases is very helpful. That makes CalVer a good choice.
For semver you could tell about 0.x.y versions meaning.
I might make a short about that.
There are other considerations. Semantic versioning is more important for publicly facing software versus, for instance a micro-service that is deployed to production with high frequency. You also need to consider if the artifact needs to be compatible with package management, such as YUM/DNF. I also don't think including the Git short hash is entirely silly. I have included it in versions for internal micro-services that deploy frequently to end the conversation about, "how do I go back to the deployed service's source code." In practice no one ever really needs to do this but also, in practice, people do all sorts of nasty things in their SCM to support this that are entirely unnecessary if the hash is present in the artifact's version.
I agree. SemVer natters mostly to technical users using an application. If, as you mentioned, it is a microservice, using build numbers or commit hashes is just as good and easier to do. Still, if that microservice is a dependency of apps developed by other teams, then those other teams are technical users of it and they might benefit from SemVer. For example, they might make decisions whether to use a newer version of the API of that microservice depending on whether it is a major or a minor change.
@@AndreiGeorgescu-j9p As I said later in my comment INTERNAL micro-services.
My question is if its a breaking change and needs to supply a major version. How the code base allowed if the change is breaking change. Breaking changes will not be allowed into the code base right. Otherwise, am I understanding differently..
Breaking changes are allowed when there is no other option, hence they are made rarely, if ever. When a breaking change is introduced, a "special" process and care is required to roll it out.
As an example, kubernetes is 10 years old now and it is still major version 1. It did not introduce a breaking change, at least not intentionally, even once. Most of it's controllers are also version 1.
Git hash as I have a CI/CD pipeline and I deliver SaaS. If I have to patch something i just branch from that hash, fix, then merge back. Team can always check the git in order to understand the changes. Semver was flawed in my case as the rate of changes coupled with feature toggles made it confusing.
Oh yeah. If you are delivering SaaS, your users do not need to know release versions and, in those cases, SemVer is not relevant as long as other teams in your company do not consume that through the API.
@@DevOpsToolkit SemVer in my oppinion is perfect for versioning contracts not implementations. 1.0.0 could hide hundreds of refactorings that are irrelevant to the outside world.
@@saigajester That's correct. That's why normally we use patches (changes that do not bring new features and are backwards compatible).
Nevertheless, if a service is only consumed by the outside world and only by humans, than semver is not relevant. That being said, that is rarely the case unless there is only one big monolith (if no other services communicate with it).
I would not throw git commit shas with build numbers in one pot. While build number varies with each run of some job, the git commit sha gives you the exact git ref which is deployed. But that is only value able for the active developer on a particular service, nothing for users and/or marketing.
SemVer is great because it is well documented and has a good acceptance. But just becomes a pain with high frequent releases.
You're right. I shouldn't put build numbers and Git SHAs into the same bucket. SHAs are much more informative and have bigger value than build numbers. We could get to the SHA through a build number but only for a short while since builds eventually get deleted while SHAs are forever.
Now, I would not say that SemVer is a pain. Or, to more precise, they are not a pain if they are auto-generated through pipelines. Patch numbers are normally generated without any intervention while for the major and minor versions we would typically add a label to a PR so that the system can know to increment those. That is indeed an extra step but it's one that I feel we should be doing even without using SemVer. There should be an indication in the PR that it is a new feature and not only a bug fix.
I think kubernetes has backward incompatible changes like deprecating ingress v1beta1. Or does that not count as it is in another repo?
Alphas and betas do not count. They are early releases meant to be used only for testing and are almost certain to be changed or deprecated before they reach stable versions. They should not be used in production. On top of that, those are separate things. There is Kubernetes itself, and then there are custom resources, ingress being one of them. Those two have separate lives and are versioned separately. Think of it as, for example Jenkins (core) and Jenkins plugins. Former is equivalent to Kubernetes and the latter to CRDs (e.g. Ingress, Deployment, StatefulSet, etc.).
@@DevOpsToolkit definitely forgot the beta argument which should be obvious :-)
Hi thanks for the video.. i have one problm like when i am running on my feature branch the Tag version is 1.0.1, whn merging with the Develop Branch its getting changed to 271.1.0,but i want to be with 1.0.1 version for the Client SDK and the Data N Service Dll... but why its getting changed? any idea
I'm not sure I understand the question. When you merge one branch into another, both are combined. Are you saying that the branch you're merging into does NOT contain 271.1.0 yet that's what you're getting?
@@DevOpsToolkit My git version file has CD version with 1.0.1, so i am working on my feature branch and merging with Develop then the version of Nuget shloud be 1.0.1 but its coming with 271.1.0.
Actually it shld be 1.0.1. based on my Gitversion file. Why its getting changed i am not able to understand
So using Kubernetes as an example, when in version 1.16.0 they removed support for some APIs in Kubernetes like "extensions/v1beta1" or "apps/v1beta2" for the Deployment Resource, shouldn't this version be a major release?
I would say "no" since beta and alpha versions are not supposed to be used (even though we all used them). They are for testing purposes only. If we would translate that to apps developed as closed source, those versions would probably never go public. But, since it's OSS, it is public and can be used by anyone. Still, they are temporary and not officially supported.
If k8s changes or deprecated v1 of its resources, then it should be v2.0.0.
@@DevOpsToolkit Good point. Thanks! About this topic, I would like to know more about automating this versioning process. Particularly in a situation when you may have different services, that alone are relevant and do something independently and so they have their own version, but are also part of a bigger product with a bunch of services.
@@andrepires5251 The situation you're describing is similar to Kubernetes. As a whole, it is v1.20.1. However, each of the resources (conceptually similar to microservices), are specific versions (e.g., Deployment v1, v2beta1, etc.).
What I'm trying to say is that you can and should version is a deployable unit (a microservice) but also a whole package.
As for automation of the versioning process... If you're using GitHub, you can adopt one of many tools that help with that (many are available as GitHub Actions as well). Most of the time, the idea is to find the latest tag, and increment the patch version by one, unless the PR has a label. If there is a label `minor` or `major` (or something similar), then the process would increment a different number and reset all those to the right. Like that, whoever creates a PR can decide whether it is an increment of the major or minor version, and if no decision is made, it'll increment the patch number.
I'll add it to my TODO list to create material about it through a practical demo.
Thanks, and in GitOps when I deliver few times in a day, what kind of version, should I use?
From the GitOps perspective, release versions are not that important. What matter is that you update manifest and that is in most cases limited to image tags (which are often the same as release versions).
... and the frequency of releases should not matter much as long as each has a unique ID.
windows has marketing versioning which is also breaking major release 😂😂
I like color versioning: ver 🟪, ver 🟧 or ver 🟥