10-20-2010 09:29 AM
I was confused for some time about the JUNOS version numbers even after the new Quarterly release format (10.x releases and higher) came out so I thought I would share what I have learned.
The basics that you probably know
What does 10.1r1 mean:
10 = 2010 IE the year of release
.1 = The Quarter 1 feature release, each quarter adds new features
r1 = Tthe release/patch/hotfix level of the 10.1 release
What about 10.1s6 ?
S releases are service level release, most often a higher number than the last r the main difference is that they are not supported by NSM and also are not generally supported for very long, they get released faster than normal to fix critical bugs.. It is almost always best to migrate to a stable r once one is available.
You can't compare 10.0 and 10.1 they are different releases and each will get their own r updates for up to a year. 10.1r1 may contain bugs that where fixed in 10.0r3 and wont be fixed in 10.1 until r2 or 3
The higher the r in theory the more stable the release... I have heard from some sources that anything less than an r3 really isn't considered reliable. So you may be better off with a 10.0r3 than a 10.1r1 for example, unless you need a feature only found in 10.1 releases.
There are extended end of life releases... Special versions will be marked as EEOL this means instead of a years support for new r releases it will have more like 3 years.... 10.4 will be the next EEOL release and I believe moving foward the 4th quarter release will always be the EEOL release.
Feel free to correct me on anything but fairly sure all of the above is accurate.
10-20-2010 08:33 PM
Yep we have a (fairly ancient) KB article which explains much the same - KB1868 (Junos 4 anyone?) - but your post is more complete and accurate so we'll update accordingly.
Another common misconception is that (for example) the first tuple (9, 10, etc) is somehow more important. But that's not true - 9.6->10.0 is the same as 10.0->10.1 - both are simply 1 major release apart. I think the "yearly" naming helps keep this clear.
Thanks for your post! - it's easy for us juniperites to forget that this stuff we live with isn't intuitively obvious to everyone else.
11-24-2010 12:03 PM - edited 11-24-2010 06:00 PM
I understand this can be very confusing, so I would like to add to the original post with what I have learned.
Consider JUNOS broken into 2 pieces (for simplicity)
Committed to a stable and consistent Software Train, Juniper has provided new software every quarter of the calendar year (As proven in the table below). Major's also have the following attributes:
There are only 2 types of Revisions.
Something worth value, is to notice the items i highlighted in RED below. The last Major release of each year (last quarter) is an "Extended End of Life" (EEOL) release. Look at the dates in the table below from FRS, to EOL. 3 1/2 years. Compare that to the standard versions (1 year give or take). I recommend only using EEOL to limit your engineers from having to spend the holidays upgrading code every year. I would even go as far as hesitating to use anything less than R3 for stability reasons. It really depends on your organizations requirements and risk tolerance.
Make sure you request a Product Incident Report (Cisco calls this a Bug scrub) for your target version. This will outline any known issues with the version you intend to use. This will help you determine if your target version will not just "work", but allow continued service on your equipment with the services & protocols you are running. You can even upgrade your service level to receive a P.I.I.R. Juniper will go as far as requesting the configurations from each hardware platform to test. Then give you their recommendations. Very reassuring if you ask me!
Hope this helps!
Product FRS Date End of Engineering Support End of Life (EOL)
02-24-2011 11:41 AM
A question I've had for awhile, but never asked: What's the significance of the number following the period in the revision number (e.g. 10.2R1.8, 10.2R2.11, 10.2R3.10)?
Is this related to an internal build number or have some date significance?
02-26-2011 10:35 PM
If I am not wrong it's like a maintenance release build number. So in case of 10.2R3.10, the R3 is a maintenance release and the ending .10 is a maintenance build number.
05-27-2011 09:08 AM
Actually that last number is a bit of internal record keeping and represents the exact ID of the build. We have often debated whether to even expose it, but there are some rare circumstances where it's been important.
12-03-2013 11:02 AM
I know this is a bit of an old thread, but I have a question about the following junos release numbers:
My question is in the "-S3" and "-D20" portion of the release strings. What is the significance of these (i.e what do they represent?)
12-03-2013 11:09 PM - edited 12-03-2013 11:11 PM
Sx: S = service-release (release meant to contain only a very limited number of fixes for certain vital problems, based on a certain R release), x = just a steadily increasing number from 1 to ... (I´ve only ever seen 4)
Dy: D = "drop" (equivalent of an Ry in the strange world of X-releases), y = also just a number but with a special scheme (D10 for the first release ~= R1; D15, D20, D25, ... consecutive releases ~= R2, R3, R4, ...; D22 for the second "service release" based on D20 ~= R3-S2)
Make sense? (My explanation, not where Juniper is headed with this ;-) )
08-21-2014 04:42 PM
Anyone know what's the default IOS and Software which is installed on the MAG 6611? I'm assuming this file is the latest admin guide for the box and software j-pulse-3.0R1-adminguide.pdf
Was wondering if anyone can confirm, please.