[ QUOTE ]
BUT, there is still justification to perform a full package build on a regular basis only to ensure that all objects are "clean". Data structure changes can sometimes cause issues with objects seemingly unrelated to the original changes - but unless you're implementing ESU's on a frequent basis into Production, its rare.
[/ QUOTE ]
I guess it depends on what kind of development you do, but for us its not "rare" and there is a definite reason to do a full build. Like I said if a public data structure changes that may be used in C code (NER, C BSFN, Table Trigger) and that object is NOT being modified and is not in the package then you need to do a full build to trigger a recompile of the C code for those objects. Keep in mind just including the object that uses the DS in the build may not be enough. You need to check out/in the object and make sure that the date on the C source files changes. During the build's compile process if the source file's date is earlier than the .obj file's date, it will not get recompiled and the old .obj file will be using during linking to build the .dll (a full build effectively forces a recompile of all compilation units so you don't have this problem). If you don't make sure that that all the C code gets recompiled with the newly sized DS type def, you risk buffer overruns, zombie kernels, unexepected behavior, etc.
You can search for a changed DS in C source code using a text editor with search in file capabilities to find dependant objects and include those objects in the update package but I have seen where things still get missed. There are also rare cases (often with type defs used in jdeCache) where a DS is used as a struct member, so now you would have to search for all objects that may be using the DS D5512345_CACHE_REC that includes the changed DS F551234 as one of its members.
Here is an abbreviated set of guidelines for my developers which seeks to some what remove human error from the equation.
1. If you change an existing tables struct, or existing key or index definition request a full build.
2. If you change a PO template and the PO DS is used in a C BSFN request a full build.
3. If you change a BSFN's function data struct (parameter list), or if you change any other public struct, or other public definition such as an enum, macro, #define, etc. that can be used by other BSFNs you should request a full build.
There is still some judgement here. If the developer is certain that a changed DS is not used in C code or the objects that have C code are in the OMW project then a full build is not required. However, there are some objects that I don't even bother to investigate. For example we have a tag table to F4211 and a tag cache struct along with BSFNs to populate the tag cache. Those are used all over the place in C code. When those data structs change its an automatic full build.
BTW, by "public" I am talking about things that go in a .h file. When we write our C code we put "private" defs for #defines, enums, static function prototypes, internal struct defs, etc. at the top of the .c file. If we need one or more of those defintions in other BSFNs we move them to the .h file and they become "public". In this way we know that if a .h file is changing, it is probably used by other C code and a full build is probably needed. If the defines that are being modified are at the top of the .c file the changes are localized to that single compilation unit and a full build is NOT required. This technique helps to make it more of a "rule" as opposed to a judgement call on whether or not a full build is needed.
I guess what I am trying to say with all this is you can't simply have a "policy" that says once a year we are going to do a full build or if we have over 100 objects we are going to do a full build. Some changes REQUIRE a full build.