ATG News RUP (Rollup) FAQ

Here is a useful excerpt from Oracle's latest ATG news letter release that discusses Oracle's current ATG patch roll up methodology.

This note briefly describes the new ATG (Application Technology Group) Minimum Patching Baseline and on-going baseline policy. As of April 2006, ATG has changed its Patching Baseline to ATG Product Family Pack H Rollup 3 (also known as ATG_PF.H RUP 3, patch 4334965, or just "RUP 3"). We have received many questions about what the minimum patching baseline and changes to it really mean. This note will describe the patching baseline policy, answer questions about how you may be affected, and give recommendations about how you should manage your applications installations given this policy.
First a brief discussion of our patching process: For any new bug fix that we make, our standard process is to make the changes in our main line (latest) files. Once the fix is successfully developed and unit tested, we create an unreleased patch containing these changes and include that patch in the next ATG RUP. This next ATG RUP remains unreleased "in-progress" for a period of time, accumulating all new fixes over that time, but also includes all previous fixes from earlier RUPS (it is cumulative). Approximately every six months we freeze the contents of the in-progress RUP and then put it through comprehensive integration testing, install testing and Applications product team certification. Although the cumulative nature of the RUP makes it large in terms of number of files delivered, the heavy investment in testing ultimately makes it safest way for you to get general maintenance updates. Another important benefit of moving to an ATG RUP is that you are no longer "alone" on some custom code level for ATG, but part of a larger community on the same code level. This allows both you and Support to benefit from the collective wisdom of customers who have already adopted that code level (We regularly update the "About doc" for each RUP with the latest in known issues or advice).
Since RUPs are only produced about twice a year, we must use a different technique to release fixes for serious defects quickly. The standard process for this case is to create a one-off patch, which involves choosing a baseline code level (such as one of the ATG RUPs) and then defining a small patch that includes the fixed files plus any other files necessary to satisfy code dependencies. This code dependency analysis can be hard to do if the fixed files have changed significantly relative to the baseline, and at some point it becomes necessary set limits on the earliest code level against which we will produce one-off patches. One-off patches have the advantage of being small, but do not go through Applications product team certification or exhaustive regression testing, and are therefore not recommended for general uptake if that same fix is also available in a RUP.
The ATG Minimum Patching Baseline defines the earliest code level against which we will develop a new one-off patch. The purpose of defining a minimum patching baseline is to keep the code-dependency analysis problem manageable and keep the number of expected testing combinations reasonable. This policy allows ATG Development to focus our efforts on providing better service to the majority of you who are staying reasonably current with ATG RUPs. As time goes and new RUPs are released we must correspondingly advance the minimum patching baseline. The new policy is that we will support the Current and Previous production Rollups (RUP N and RUP N-1) as baselines for general one-off patching. For example: since ATG RUP 4 was released on August 4 2006, we are shifting to a policy where ATG RUP 3 is the minimum patch baseline and ATG RUP 4 is default patching baseline (with some lag-time to allow for uptake of RUP 4).
Please note that the minimum patching baseline only affects the production of new ATG patches. All existing patches that were released for issues on earlier baselines will remain available for customer download. Earlier code levels are fully supported, in that Support and ATG Development will analyze any reported issues, even from earlier ATG code levels. But if the resolution to a reported issue requires the creation of a new one-off patch, then that patch will have a dependency on at least the minimum patching baseline.

Here are some frequently asked questions:
Q: I do not plan to upgrade to ATG RUP 3 (or RUP 4) for many months, can I expect continued support during this time?
A: The baseline policy does not affect whether you are considered supported. Support and ATG Development will investigate all reported issues to the best of our ability. The baseline policy only affects the development of new patches. If you are not on the ATG minimum patching baseline and require an emergency fix against your code level, it might be possible to produce a backport for you, but this will require a backport request, business impact justification, and VP approval.
Q: I am running happily on an older code level, should I plan to upgrade to the ATG minimum patching baseline?
A: Anyone not currently on the ATG Minimum Patching Baseline (RUP 3) is advised to make plans to update to ATG RUP 4 by the end of this calendar year. ATG RUP 3 is the minimum baseline, but if you need to upgrade you might as well move directly to RUP 4. You should NOT wait for a reason to move to RUP 4, staying current with ATG RUPs should be a regular planned activity, even if a system appears to be running fine. The RUPs contain a number of performance, stability, functional, and security fixes that are not available through any other mechanism, and in any case it is better to move to ATG RUPs under controlled conditions, rather than as a side effect requirement from applying some other change.
Q: Are existing patches and technology certifications affected by the new ATG Minimum Patching Baseline?
A: No. Existing patches and technology certifications that were tested against earlier ATG code level will remain valid options for you. For example, the 10gR2 Database certification requires 11.5.10 CU2, and this fact is not changed by the new ATG baseline. Similarly, all existing product and ATG patches that work against earlier code levels remain available. The baseline policy only affects production and testing of new patches from ATG.
Q: Will application product team patches now require the ATG Minimum Patching Baseline as a pre-requisite?
A: This is a decision that application product teams will make independently. In general, applications patches should list their minimum ATG code level as the prerequisite.
Q: Will ATG RUP 4A work on 11.5.9 or earlier?
A: Yes, but with some caveats. Our goal with ATG RUPs is to release all known defect fixes while maintaining 100% backward compatibility with existing applications product code (which we understand can be more difficult to upgrade than technology code). ATG RUPs are in fact the only patches from ATG that go through a full backward compatibility certification program by all Applications product families. Any behavior change at the technology layer carries some risk of causing an unintended side-effect at the application product level, and we find and correct most such issues during RUP certification. But in some cases an in-compatible ATG change must remain in effect for security or stability reasons or is discovered too late. Incompatible changes at the ATG level may require a small "co-requisite" patch for affected application products to continue operating as normal. Make sure to read the "About" document for the ATG RUP carefully to find the latest news on known co-requisite patches for Applications products. We are continually striving to eliminate unnecessary co-requite patches and prevent the introduction of new ones.
The ATG Minimum Patching Baseline and RUP policy are intended to provide the best long-term product quality for you, offering a predictable and sustainable approach to continuously improve the E-Business Suites stability, performance, and security. We encourage everyone to make proactive adoption of ATG RUPs a standard practice.

11i: CPU October 2006 - E-Business Suite Impact

For those who are in the process of evaluating the impact of the recent October CPU patches as it concerns the E-Business Suite, Integrigy has published a useful analysis report. 11i: CPU October 2006 - E-Business Suite Impact