On 15 Jan 2009, at 21:16, Sriram Natarajan wrote: > Option 1: Develop patch framework so as to release patch train > separately for each component within web stack. For example, apache > will have its own patch id (say 11111-01 etc) and mysql will have > (22222-01) etc. Customer will need to download patch for every > component within webstack separately and install them. > > Cons > - Customer deploying a whole stack will need to download 10 > different patches from Sun Solve . This can be minimized by > requesting Sun Patch team to provide us with Web Stack patch cluster.
Isn't that mitigated altogether by providing a meta-patch (product code "webstack") that serves merely to import all the component patches as dependencies? FWIW, my gut reaction is to prefer Option 1. > Option 2: Consider Web Stack as a single product and develop > framework to release a single patch train (11111-01 etc) that > includes all components (say apache, mysql etc) within this patch. > Now, a single patch can cover multiple packages and all the > packages that are installed on the system will be patched. Let us > say if new packages are installed on a later date they can be > patched with the same patch as well. > Cons > - Customers will be forced to upgrade all the packages (aka > components like Apache, MySQL) installed on their production system > even if they are interested in getting only a MySQL patch. - Makes it much harder for a customer to maintain local customisation of a chosen component of webstack. - A bigger mess to clear up if an update crashes out in an unclean state. -- Nick Kew
