Axton, I hear you. But your starting to drift into version control stuff, and I think there are good open sourced solutions for that. I do agree that version/release control are important things, but I want to walk before we try to run. :)
As far as OOB customizations go.... I think the answer is a bit simpler than making the installers do all the work. A) The GGUID's allow the installers to find the "right objects". B) Before the install the customer needs to review all Removed objects (fields, workflow, etc) to verify that those removals will not break anything they have customized. ( This is mostly driven by better change documentation for the OOB patches/versions. ) C) One of the main pain points for OOB customizations are in the form views. BMC adds a new field to a form an they have to put it on the form somewhere for the users to be able to use it. But the customer has totally moved stuff around because they did not want to see "BMC Software" (or the "blue" color from that "state up north") on all of their UI. Your solution would leave the installer with the task of "doing the right thing" with the customizations. I think the right answer is to extend the "enable/disable" logic to views. If the customer wants a different view, then they copy the view and disable the OOB view. Then they make all the changes they want. (Only one enabled view for a given local/label would be allowed, but multiple disabled views per local/label should be fine.) The installer only changes the OOB view. Yes the customer needs to decide how to make changes to their view after the installer is finished, but that is the price you pay for changing the look and feel. ( IMHO, the customer took ownership of it, and they have to keep maintaining it. ) And changes like "Adding/Removing of fields" should be well documented and identified for customers to access before they install the OOB patch/version. Now after the customer finishes applying the patch to dev and fixing their custom UI's then they can get an updated def to be applied to prod after they finish the installers. And all should be good again. C) There could still be issues with workflow too. However, the OOB objects that were disabled before the patch/install should be "re-disabled" at the end of the patch/version install process too. (Again, GGUID would allow this logic to work efficiently.) D) After the install the customer needs to review any and all New objects (fields, workflow, etc) Maybe some of the customizations can now be removed? Maybe they need tweaked? etc... It is not a fully automated "patch any change you made", but it would greatly reduce the pain for most customers. (And the install verification should still be able to work 100% of the time. :) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 8/15/07, Axton <[EMAIL PROTECTED]> wrote: > A checksum that accompanies the gguid (generated based on the object > properties and gguid) for the object would be nice as well. This > could be used by things like upgrade installers to generate a list of > objects that have been changed but retained the original gguid. App > installers could then be aware of which objects to update and which > ones to include in a report of exceptions. This would probably work > very well for things like application patches, but still miss the > target for full application upgrades. > > <dreaming> > It would be nice to see BMC get into the practice of providing patches > for the applications on a regular basis, in an automated way (not the > import def X, arx Y, then def Z). The application versions could then > be tags at patch level A, B, C. etc. > > The patch process could be an executable or arf plugin that simply > retrieves a list of available patches from a BMC patch server, > generates a list of the patches, then gives you the option of whether > or not you want to apply one or all of the available patches. No more > upgrades, just staying current with the patches. > </dreaming> > > Axton Grams _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
