[c-nsp] 12.2SXF?

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lists at hojmark.org wrote:
>>In the general IOS naming process rebuilds are kept to bugfix
>>only.
>>
>>I'm no sure if SE deviates from that or not.
> 
> 
> For the past year or so, the 'DSBU software' (3550, 2970, 3560,
> 3750) has gotten new features with each new letter (like SEA ->
> SEB -> SEC).
> 
> The bugfix-only rebuilds are marked with a number *after* the
> letters (like SEB2, SEB3).
> 
> Prior to this they used only the maintenance number (like
> 12.2(18)SE -> 12.2(20)SE -> 12.2(25)SE), so I guess you could
> say they've gotten more in line with the C6K software.
> 

This is like the "T" train model of the mainline releases.  A release like
12.3 and 12.3T share their maintenance release numbers and they increment
monotonically.  So the first release of 12.3 is 12.3(1) and the earliest
release of T could only be 12.3(2)T.   If there are 3 maintenance releases
of 12.3 before the next (2nd) release of T, then it would be 12.3(6)T
(since (3), (4), and (5) would be the mainline maintenance releases).  And
the T train is in sync with the mainline so that a fix for a bug that is in
12.3(5) is also present in 12.3(6)T.  Having the two releases balances the
need for bug fixing vs the desire to introduce new features.

All of the 12.2S and their derivatives started down this same path, but for
various and differing reasons (see below), they had to deviate from that model.

> Now, if only the C4K people would do the same thing...
> 

Now, they had to change because at the time there was no release beyond
12.2(20)S for them to sync with and introduce their new features.  The only
option to introduce those new features was to follow the 12.2SX model of
incrementing the trailing, third letter.  I wasn't happy about the decision
since it introduced another numbering inconsistency, but couldn't offer a
better solution given some of the many limitations of the software tools
used for development, manufacturing, release etc.

Unfortunately, all of the variations created out of necessity are very
confusing and a fundamental rethinking is needed to create a consistent
release naming/numbering methodology that can balance both
stability/maintenance needs and feature velocity needs simultaneously and
consistently across all platforms.  As you can guess, no small undertaking....

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFDA8tAE1XcgMgrtyYRAjtCAKC6aTMgKydIqbzZpxThSbO2vUfyzACfZ47R
pCVANEycAOe0rZ+jwfsMqio=
=aBvg
-----END PGP SIGNATURE-----