[nsp] FW: URGENT: New IOS Release Numbering Scheme

Fri Apr 2 11:02:09 EST 2004

yeah, right....

/* Del Hudson Contr 61CS/SCBN */

-----Original Message-----
From: Tomas Daniska [mailto:tomas at tronet.com]
Sent: Friday, April 02, 2004 6:06 AM
To: cisco-nsp at puck.nether.net
Subject: [nsp] FW: URGENT: New IOS Release Numbering Scheme

sorry for being late, but applies ex-post :)

> ----- Forwarded message -----
> 
> Date: Thu, 1 Apr 2004 09:54:52 -0800
> Subject: URGENT: New IOS Release Numbering Scheme
> 
> Effective immediately, IOS will adopt a new, more flexible 
> version numbering scheme which allows unprecedented 
> flexibility and expandability.  This is the first major 
> release numbering change since 1994 and we expect it to be 
> embraced by developers and customers alike.
> 
> Release numbers will now be represented as a chain of 64-bit 
> quantities, expressed in hexadecimal.  In order to allow 
> maximum flexibility, each address will also be accompanied by 
> a 64-bit bitmask in order to delineate the size of the 
> variable length fields.  Since we can chain these 64 bit 
> quantities, the numbering scheme is infinitely flexible, and 
> the trauma of future renumbering should be minimized.
> 
> The fields of the new version number are
> 
> 1) Numbering Scheme Version Number (Will start at "0")
> 2) Block type (0= version, 1=sync point 2=patch)
> 3) Major Release Number (e.g. 12)
> 3) Minor Release Number (e.g. 2)
> 4) Maintenance Release number (e.g. 21)
> 5) Interim build number (0 for non interims)
> 5) Rebuild Number (e.g. 2)
> 6) Rebuild Interim Number (0 for non interims)
> 7) Train Family (3 characters in 7-bit ASCII)
> 8) Pointer to patch block (future ION releases, 0 when unused)
> 9) Pointer to sync point block (0 if unchained)
> 11) (Future blocks added as needed)
> 12) Reserved termination sequence
> 
> The version number is expressed as a block of n-64 bit 
> numbers, with the first 64 bit number representing the 
> "master" version number of the release, and all subsequent 
> blocks used by the pointers (nth block).
> 
> The 64 bit blocks appear in tuples:  version/mask, 
> version/mask, version/mask until the reserved termination 
> sequence of  44:55:48 appears, marking the end of a block.  
> In case 44:55:48 needs to appear in the context of the 
> number, it should appeat TWICE in a row (44:55:48:44:55:48) 
> in order to denote that it is NOT the end of the block.  The 
> bitmask for each block takes the form  
> 0000000111111100000001111111... where each alternating 
> sequence of zeroes and ones deliniates each new field in the list.
> 
> When pointing to another field in the version number block, 
> you should count the number of fields to offset in order to 
> reach the "numbering version"
> field of a new block.  This allows the use of mixed numbering 
> nomenclature, and further increases flexibility.
> 
> For example, if the sync version block is 10 fields away, "A" 
> should be entered into the pointer field.  All fields are 
> addressed relatively.  It is suggested, though not required 
> that the minimum field length be 8 bits for improved readability.
> 
> If the field does not end in a multiple of 64 bits, the 
> leftover bits should simply be filled in (padded) with zeroes.
> 
> Examples:  For 12.2(18a)SXA4, you can make the collowing conversion:
> 
> 12 is C in hex
> 2 is 2 in hex
> 18a is 12 in hex (we will drop the "a" for simplicity) SXA is 53:58:41
> 4 is 4
> 
> So the new simplified  version number would become
> 
> 00:00:0C:02:12:00:04:00
> 00:FF:00:FF:00:FF:00:FF
> 53:58:41:00:00:44:55:48
> 00:00:00:FF:00:FF:FF:FF
> 
> I'm sure the additional clarity of the release number is 
> completely self evident.  A more clever engineer could 
> compress the fields and not waste so much space.  For 
> example, compressing the numeric fields to minimum size
> 
> 32:92:a7:71:06:00:44:55
> 43:04:10:1f:c0:33:00:00
> 48:00:00:00:00:00:00:00
> 00:FF:FF:FF:FF:FF:FF:FF
> 
> The two version numbers are equivalent.  The 8-bit delineated 
> is preferred for readability, but the compressed form can 
> also prove useful.  This is yet another benefit of the new scheme.
> 
> Also this new scheme allows independent train numbering.  
> Suppose a new version 1.0 SXQ branch were created off the 
> 12.2(18a)SXA4 branch?  The version number could simply be expressed as
> 
> 00:00:01:00:00:00:00:00
> 00:FF:00:FF:00:FF:00:FF
> 53:58:51:04:00:44:55:48
> 00:00:00:FF:00:FF:FF:FF
> 00:00:0C:02:12:00:04:00
> 00:FF:00:FF:00:FF:00:FF
> 53:58:41:00:00:44:55:48
> 00:00:00:FF:00:FF:FF:FF
> 
> 
> Additional chaining is possible, so 
> great-great-great-great-great grandchildren braches will be 
> possible, and clearly enumerable.
> 
> Training on the new scheme is available online, and will be 
> required for all customer support engineers and sales 
> engineers.  Training is available at 
> http://glms.cisco.com/ems , search for the course name:  
> Cisco IOS Release Numbering Course:  IOSREN601ENG.  Be  sure 
> to complete the associated mastery assesment.  Results will 
> be forwarded to your individual management teams.
> 
> I'm sure everyone can see the benefits of the new numbering 
> scheme, with its inherent elegance and flexibility.  Since it 
> is all binary, integration and implementation into Clearcase, 
> DDTS, CDETS and C3 should be trivial.
> Customers are expected to have no problems with the new scheme.
> 
> Remember, this is all effective immediately, April 1, 2004.
> Training must be complete by April 15, 2004.
> 
> Have a nice day.
> 
> Sincerely,
> IOS Business Council Representative
> 
> ----- End forwarded message -----

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/