Please let me know difference between service packs and patch.
An Authentication Manager version has at least 4 numbers in a release;
Major version; 6, 7 or 8, e.g. version 8.0 and 8.1 are the same major version but not the same version release
Minor version; 6.1, 7.1, 8.0 (0 minor version), 8.1 (minor version 1) and 8.2 (minor version 2 for major version 8)
Service Pack, i.e the third number; 7.1 SP4, 8.1 SP1 (shorthand is 188.8.131.52) 8.2 SP1 (8.2.1)
patch, i.e. fourth number; AM 7.1 SP4 P32 = Auth Manager 7.1 Service Pack 4 with patch 32 or 184.108.40.206,
and AM 8.1 SP1 P15 or 220.127.116.11.0
and AM 8.2 SP1 P6 or 18.104.22.168
patches are roll-up, in other words to get from AM 8.2 SP1 to AM 8.2 SP1 P6 is only one patch, the latest patch 6, not six patches, P1, P2, P3, P4, P5 and then P6
RSA strongly recommends (can you say 'requires') that you patch Primary first then Replica(s)
To further confuse things, back in AM 8.0, and 8.1 you could attach an 8.1 replica to an 8.1 SP1 Primary, but since AM 8.2, every Service Pack and minor and major version upgrade 'breaks' replication. So you need to upgrade your replicas soon after the Primary is upgraded, and if you apply two of the following, e.g. a minor version and then a service pack to the primary, you will not be able to upgrade your replicas! You will have to redeploy them.
All the RSA products follows above mentioned versioning pattern?
Appreciate your support!
I am only sure about Authentication Manager, I'm not familiar enough with versioning on other products such as Archer or NetWitness, etc..., you might need to post this same question under other product forums
For various practical and historical reasons, the same versioning pattern is not followed for all RSA products. Even within the RSA SecurID Suite, the numbering scheme differs somewhat between components. For example, RSA Authentication Agent SDK 8.6.1.
An easy place to browse the major/sub-major version numbering schemes for various RSA products, is the Product Version Life Cycle pages.
To see how minor versioning works for a product, go to the RSA Link page for the product, then click on Advisories > Product Advisories. You will see listed the historical release announcements for the product, which include version numbers in the title. Each announcement will give a high level description of what changed in that version.
For all products, there is a general hierarchical principle in the version numbering. The first number will be a major release number, the second will be a sub-major release number. Subsequent numbers, however they are presented (as dot numbers, service packs, patches or hotfixes), will represent progressively more minor sets of changes and fixes.
"Hotfix" numbers, mentioned above, are often represented as "HFn", where "n" is the hotfix number, e.g. HF3. A hotfix represents a fix, usually for a single issue, that needs to be made available to some or all customers as quickly as possible. Hotfixes generally should only be applied if you are experiencing the exact issue that a particular hotfix addresses. They are also usually not cumulative. For some products, such as RSA Adaptive Authentication on Premise, most hotfixes are not published on its Product Advisories page, as they are usually only suitable in very specific circumstances. Consquently, you often will not see a hotfix in the Product Advisories page, but RSA Support will advise you if a hotfix should be applied, and will make it available to you.
Sometimes you may also see build numbers, which are 3 or more digits long. As the name implies, these represent a specific build, or compilation, of the product. The number itself usually has meaning only to RSA's engineers, but should be included, if you see it displayed in a version string, together with other version information when reporting problems to RSA Support. RSA Identity Governance and Lifecycle is an example of a product that uses build numbers for RSA internal use only. In contrast, RSA Digital Certificate Solutions is an end-of-life product which was unusual in that it used build numbers as part of its official version numbering scheme.
SaaS-based products are different again. They will often only include a major and sub-major release number and no service pack, patch, hotfix, build or other numbering. RSA SecurID Suite's Cloud Authentication Service is an exception, as it uses no conventional version numbers at all. Instead, month and years are used, e.g. November 2017 release. Once again, Release Notes explain what enhancements and fixes are included, regardless of the versioning scheme.
Not all updates are cumulative. Usually updates may only be applied to a specific older version or set of versions. It is very important to read the Release Notes and any Install/Upgrade/Migration instructions to understand the contents, procedures and restrictions for any update RSA provides. Do not assume that an upgrade method that you followed previously will be correct for every subsequent update.
Some products have RSA Knowledge Base articles that explain versioning. Otherwise, as Jay Guillette explained, if you still have a specific question about versioning in another RSA product, please post the question to that product's forum.
Not sure how deep you want to go but Service Packs will typically contain new features and fixes. Patches are just fixes. All of them roll up so taking the latest will get you all the previous content.
Retrieving data ...