Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Mon Oct 09, 2006 11:00 pm Post subject: Release Versioning
We are in the initial stage of Implementing ITIL.
We had meeting today on Release Mgt. The debate was on the
1.Release Identification and Versioning
The doubt that was raised was "Do we need to have new Release versions based on the Major/Minor/Emergency release or does the versions have to be for the Delta/Full/Package release"
As I can see from some of the topics in the forum different companies are using different methods. Do let me know the pros and cons of both.
Well I think verion numbers should be based on both criterias. Let me write my thoughts using an example. your orgnaization develops software, the current verion of the latest package released is PK3.2. Bugs start to appear and they are addressed by emergency fixes, lets say PK3.2-HF1, PK3.2-HF2, ..., PK3.2-HFx and requests for enhancements are being addressed with patches PK3.2-patch1, PK3.2-patch2, ... , PK3.2-patchx
All those emergency fixes, enhancements, and other are at a certain stage introduced in a new package PK3.3 from which cycle continues.
I hope I gave a clear address to the right question.
The Major_Identifier is used for significant architectural releases.
The Medium_Identifier is used for normal/standard releases.
The Minor_Identifier is used for patch and and minor point releases.
Something to note is that ITIL does not address "Product Management". As a result, there is a significant gap in ITIL and its implied data model, as there is nothing to bind a Release entity to.
A Product is a trackable entity (which ITIL does not speak of) and a Product can have one or more Releases.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Hey Thanks Ziad....
But if we go by what you have suggested, i have one more query.
Let me put down what i have understood....
At any point of time an application should have a single current version in the live environment. So as you mentioned let the current version of the latest package released is PK3.2
When the first bug appears you can fix it by emergency release and call it PK3.2-HF1(Current version). But the doubt i have is "Why cant it be called as Delta release?" and have the current version as (say) PK3.2-D1. An application can't have two versions - one due to emergency release and one due to delta release right?
Anyway your inputs have given some very useful new dimensions of thinking. Thanks again.
P-De
Last edited by P-De on Tue Oct 10, 2006 4:37 am; edited 1 time in total
Even though Frank's answer is more practical, I wish to continue our discussion and answer your questions for the sake of information. I may have understood things wrong for example, and that's a good opportunity to correct my knowledge.
The software/package in production is comparable to the major_identifier in Frank's example.
I mentionned Emergency Fix on purpose in my example because it is a different classification than a delta release.
You're right about something, the version should contain three identifiers as in Frank's example, I was basing my answer on the version numbering within an organization I know and yes, I missed a part. The naming was: Product-Version_Patch-version_HF-version.
I would rather combine the 6 types and come up with 4:
- Delta Release: that I called patch in my earlier example, new piece of code added to existing SW (that covers minor and major)
- Package Release: Full or Delta or Full+Delta (Full Release is covered here, so no need to have it as a seperate type)
- Emergency Fix: a hot fix required to be deployed asap to address a certain issue.
Sounds good to me but Frank's method is more practical and this is how the Service Support ook describes the release identification.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum