On Thu, Oct 25, 2007 at 04:17:18PM +0200, Lukas Rovensky wrote: > You are right, I asked about something different and maybe I was just > thinking too much the 'patch way'. The scenario I had in mind is like the > following -- a customer has a problem, a fix is implemented and needs to be > verified. In such situation it is now possible to create a restricted > patch, which the customer can install but no additional patch can be > installed on top of it. Once the fix is verified then a regular patch can > be created (the restricted patch is uninstalled and the regular patch can > be applied).
Ah, okay. Yeah, if you want to do something like that, you can, except that it'd still be up to the customer to freeze it manually. You'd increment the branch version (probably adding another component from the version to which the fix was being applied), and have the customer freeze the package to that branch version. You could then actually improve the "patch" along that branch until you and the customer were satisfied, allowing the customer to apply the updates freely along that branch. Once you decided it was okay to bring out of testing, you can apply the fixes to the main source tree, and release a new version as you normally would, and the customer would unfreeze that package. Think of it as a stream of change whose lifetime is the testing of the fix to a particular problem, and possibly directed and/or available to only one customer. You could do this with multiple packages in synchrony by specifying an incorporation (possibly unique to this problem) that incorporated all the packages participating in the process. Danek
