Current JUNOS Release numbers explained

[SomeITGuy]

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.

[SSHSSH]

Thanks

[Automate]

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.

-Keith

[Tharos]

Thanks very much. This was really useful. I was looking for that information in KB without success.

[xintao@5173.com]

roger that

[smashmars]

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)

• Major Designation - the first 3 numeric values on releases post 11/15/2009 (i.e. 10.0+). 

• Revision Designation - the proceeding values after the Major number as indicated by the letter "R"

Major Releases

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:

• Contain New Services/Features
• Predictable End of Engineering Support Date
• Predictable End of Life Date

Revision Releases

There are only 2 types of Revisions. 

• Initial - R1 (Contains New Services/Features as listed in previous section)
• Bug Fixes - R2, R3, R4

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)

JUNOS 10.2	05/15/2010	02/15/2011	08/15/2011
JUNOS 10.1	02/15/2010	11/15/2010	05/15/2011
JUNOS 10.01	11/15/2009	11/15/2012	05/15/2013
JUNOS 9.6	08/06/2009	05/06/2010	11/06/2010
JUNOS 9.5	04/14/2009	02/15/2010	08/15/2010
JUNOS 9.4	02/11/2009	11/11/2009	05/11/2010
JUNOS 9.31	11/14/2008	11/14/2011	05/14/2012
JUNOS 9.2	08/12/2008	05/12/2009	11/12/2009
JUNOS 9.1	04/28/2008	01/28/2009	07/28/2009
JUNOS 9.0	02/15/2008	11/15/2008	05/15/2009

Source:http://www.juniper.net/support/eol/junos.html

[aweck]

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?

[mshah]

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. 

[Automate]

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.

-Keith