I'm looking to learn about what limits apply to Patch Orgs. For example:
How many patch orgs can I spawn off one release?
Can I upload unlimited versions from a patch org as long as they don't add new components?
The context behind my question relates to Source Code Escrow and given 'special' clients, whether incrementing a minor release and spawning a Patch Org would be a legitimate escrow mechanism.
The patch mechanism is a way to create one branch (= one patch org) from each version of the trunk (= packaging org). So with an org containing say version 1.5, a single patch org can be created that goes through versions 1.5.1, 1.5.2, 1.5.3 and so on. When to create a new version is your choice i.e. the new version could be identical to the old version if you really wanted.
(The numbering scheme is major.minor and then major.minor.patch if patches are created.)
So for your question 1), you can create one patch org per version i.e. one for 1.5 and one for 1.6 and so on.
On your question 2), we are in the many hundreds of versions in the packaging org and have gone up to x.y.11 in a patch org. Hopefully there is no hard limit to the number of versions...
For escrow, if only one customer wants an escrow version of 1.5 then that approach would be a good one. They can be handed over the credentials of the 1.5.1 org (that might a year later be say the 1.5.7 org) and can make the limited modifications that patches allow from then on independently of others.
But with two or more customers for version 1.5 that doesn't work. And I don't think the workaround of creating multiple identical versions - 1.5, 1.6, 1.7 etc - is going to work unless you know up front exactly how many customers you will have for every "real" version. Let alone the confusion that having multiple identical versions might cause.
I'm very interested in what other have to say (and to be corrected if I've missed something) on this subject as escrow has come up more than once in my company.
