UchePhilz · April 11, 2019 23:12
diff --git a/versioning_the_chaos b/versioning_the_chaos
 Versioning The Chaos

 You may find yourself in a company or team where new features are released as hotfixes,A Team where Alpha & Beta are one and the same, in this kind of environment the end users become the testers of your application.
 
 You are not alone! A lot of software engineers have found themselves stuck in such situation. Some left for a more organized company, others endured till the end, while some found a way to manage the situation by versioning.
 
 Why versioning?
 My answer is that it gives your brain the chance to pace itself. Studies have shown that writing out your tasks helps eliminate stress and makes people more organized & focused on accomplishing their tasks.
 
 Let me use a real scenario to illustrate how versioning can combat chaos.
 
 Once I was working on a web application and while building a feature of the application, I kept getting new features, change requests and bugs here and there.
 Needless to say that what should have been a simple web application soon became overwhelming.

 #1 Categorize Every Task
 I ordered my tasks by priority then reordered by ease of implementation.
 Then I began to work my way up from there:
 I took worked on the Easiest High-Priority Task then the Toughest Low-Priority Task, making sure to deploy a build for the Testers either by the hour or by the end of the day.

 When I did this, I realized that I was more efficient in delivery.

 You may wonder where versioning comes into this because you are expecting to see something with v1.0 or v3.91.3.
 The truth is that at the time, I didn't know much about that aspect of versioning; I just knew that I needed to properly organise the tasks on my table if I were to keep my sanity.
 
 The next step is numbering your build & releases.. Which is what I am sure you are eager to hear.
 
 2# Choose the right Versioning Scheme
 Discovering versioning meant that I could now properly order tasks, so I devoted some time to some research.
 My initial plan was to use a versioning scheme like [release].[hotfix].[sprint]

 [sprint]: are the tasks you have cleared up with a period
 [hotfix]: this represents the number of hot fix you made within a sprint
 [release]: the number of significant changes you've made to the software.

 When I came up with this, I thought It was flawless, I thought it was the magic I was looking for, in that moment while I felt like I was Charles Babbage!
 
 I made some more research on versioning and found NumVersion Struct, It was clear and simple enough to implement and it seems really appealing because Apples Inc. uses it.


 How do you Version the Chaos?
 [Find more details of the version scheme at: https://gist.github.com/sjehutch/98f31b79495901e8e0ef]

 [major revision].[minor revision].[bug revision]-[stage][stage revision]

 Following the link will get you the detailed description of the number format and other information; I'm only here to help you understand the usage.
 
 Major Revision: This is a significant revision that gets released to the client, it might be updates that affects the whole platform, for instance:
 Changing the application architecture to be multi-tenant based
 Adding theme settings that affects the look and feel of the application.
 Adding currency options for the user, whereby when a user chooses to use a certain currency, that price of all item of the website would be updated.
 These are all examples of major revision, it make also be a change to the language, or framework.

 Minor Revision: This includes updates that are scope-based, in which change would only affect a portion of the software.
 Examples are:
 Adding a ‘search input’ field to view.
 Adding a button to a view
 Any other change that affects a scope or two in your software.

 Bug Revision: This is pretty self explanatory, when you fix a bug in major or minor revision, the bug revision digit goes up!

 Stage: This is the list of stages: dev, alpha, beta, rc, final. It would do you good to read up on this. I may have to take some time in the future to write about the stages, because you’ll need have a proper understanding of what dev, alpha, beta, rc, final stages are.

 Stage Revision: Stage Revisions are basically commits to your repository.
 
 
 How to begin:
 Chaos is chaos and in trying to make sense of it, it will not be very easy to start versioning because you will most likely be up against a lot of hindrances, such as:
 Time constraint
 Pressure to deliver
 Enormity of task.

 You’ll probably feel like there is no time to consider grouping your tasks.

 Doubt: You may wonder to yourself, “What use is this for?” You may question the relevance of versioning as it neither makes the code more efficient nor get does it the job done.
 If anything, versioning seems like just one more task to accomplish. 
 Pressure to deliver: Too many people may be shoving Jira task down your throat, making you feel like you’ll soon explode.
 
 The first step is to not be in a haste. Take your time.
 I can virtually feel hundreds of sleep-deprived energy drink powered crazed programmers’ eyes turn on me as they read this.
 Woah, don’t shoot the messenger, people! I am also a programmer, I still use JSP (Old Gs) and AngularJs(for the new Gens)
 What I am saying is that versioning does not need to be one more task on your plate.

 Think about versioning when walking home, eating, taking a shower, etc...
 Just relegate it to the category of free thinking, leave it to your subconscious, pick up from your subconscious, and iterate till it all seems easy.

 Then take the next step and categorize your tasks, identify if you are doing a hotfix to a minor revision, identify the stage your development is on, ask yourself, "Am I the only one with the code?" If yes, then it is that is your dev stage and so on


 I'll stop here and let you figure the rest on your own. But with this, you are definitely ready to Version The Chaos.
	Versioning The Chaos

	You may find yourself in a company or team where new features are released as hotfixes,A Team where Alpha & Beta are one and the same, in this kind of environment the end users become the testers of your application.

	You are not alone! A lot of software engineers have found themselves stuck in such situation. Some left for a more organized company, others endured till the end, while some found a way to manage the situation by versioning.

	Why versioning?
	My answer is that it gives your brain the chance to pace itself. Studies have shown that writing out your tasks helps eliminate stress and makes people more organized & focused on accomplishing their tasks.

	Let me use a real scenario to illustrate how versioning can combat chaos.

	Once I was working on a web application and while building a feature of the application, I kept getting new features, change requests and bugs here and there.
	Needless to say that what should have been a simple web application soon became overwhelming.

	#1 Categorize Every Task
	I ordered my tasks by priority then reordered by ease of implementation.
	Then I began to work my way up from there:
	I took worked on the Easiest High-Priority Task then the Toughest Low-Priority Task, making sure to deploy a build for the Testers either by the hour or by the end of the day.

	When I did this, I realized that I was more efficient in delivery.

	You may wonder where versioning comes into this because you are expecting to see something with v1.0 or v3.91.3.
	The truth is that at the time, I didn't know much about that aspect of versioning; I just knew that I needed to properly organise the tasks on my table if I were to keep my sanity.

	The next step is numbering your build & releases.. Which is what I am sure you are eager to hear.

	2# Choose the right Versioning Scheme
	Discovering versioning meant that I could now properly order tasks, so I devoted some time to some research.
	My initial plan was to use a versioning scheme like [release].[hotfix].[sprint]

	[sprint]: are the tasks you have cleared up with a period
	[hotfix]: this represents the number of hot fix you made within a sprint
	[release]: the number of significant changes you've made to the software.

	When I came up with this, I thought It was flawless, I thought it was the magic I was looking for, in that moment while I felt like I was Charles Babbage!

	I made some more research on versioning and found NumVersion Struct, It was clear and simple enough to implement and it seems really appealing because Apples Inc. uses it.


	How do you Version the Chaos?
	[Find more details of the version scheme at: https://gist.github.com/sjehutch/98f31b79495901e8e0ef]

	[major revision].[minor revision].[bug revision]-[stage][stage revision]

	Following the link will get you the detailed description of the number format and other information; I'm only here to help you understand the usage.

	Major Revision: This is a significant revision that gets released to the client, it might be updates that affects the whole platform, for instance:
	Changing the application architecture to be multi-tenant based
	Adding theme settings that affects the look and feel of the application.
	Adding currency options for the user, whereby when a user chooses to use a certain currency, that price of all item of the website would be updated.
	These are all examples of major revision, it make also be a change to the language, or framework.

	Minor Revision: This includes updates that are scope-based, in which change would only affect a portion of the software.
	Examples are:
	Adding a ‘search input’ field to view.
	Adding a button to a view
	Any other change that affects a scope or two in your software.

	Bug Revision: This is pretty self explanatory, when you fix a bug in major or minor revision, the bug revision digit goes up!

	Stage: This is the list of stages: dev, alpha, beta, rc, final. It would do you good to read up on this. I may have to take some time in the future to write about the stages, because you’ll need have a proper understanding of what dev, alpha, beta, rc, final stages are.

	Stage Revision: Stage Revisions are basically commits to your repository.


	How to begin:
	Chaos is chaos and in trying to make sense of it, it will not be very easy to start versioning because you will most likely be up against a lot of hindrances, such as:
	Time constraint
	Pressure to deliver
	Enormity of task.

	You’ll probably feel like there is no time to consider grouping your tasks.

	Doubt: You may wonder to yourself, “What use is this for?” You may question the relevance of versioning as it neither makes the code more efficient nor get does it the job done.
	If anything, versioning seems like just one more task to accomplish.
	Pressure to deliver: Too many people may be shoving Jira task down your throat, making you feel like you’ll soon explode.

	The first step is to not be in a haste. Take your time.
	I can virtually feel hundreds of sleep-deprived energy drink powered crazed programmers’ eyes turn on me as they read this.
	Woah, don’t shoot the messenger, people! I am also a programmer, I still use JSP (Old Gs) and AngularJs(for the new Gens)
	What I am saying is that versioning does not need to be one more task on your plate.

	Think about versioning when walking home, eating, taking a shower, etc...
	Just relegate it to the category of free thinking, leave it to your subconscious, pick up from your subconscious, and iterate till it all seems easy.

	Then take the next step and categorize your tasks, identify if you are doing a hotfix to a minor revision, identify the stage your development is on, ask yourself, "Am I the only one with the code?" If yes, then it is that is your dev stage and so on


	I'll stop here and let you figure the rest on your own. But with this, you are definitely ready to Version The Chaos.