Typically, this decision is driven by the Application deployment. Are applications isolated to Pods or not. The most common upgrade schemes I've seen are:
1) Odd / Evens Entire Fabric w/ Soaking Period In Between
Maintenance Period 1 : All Pods / Odd Switches
Maintenance Period 2: All Pods / Even Switches
2) Pod by Pod Upgrade w/ Soaking Period In Between
Maintenance Period 1 : Pod1 / All Switches
Maintenance Period 2: Pod2 / All Switches
Maintenance Period n: Podn / All Switches
3) Odd / Even & Pod by Pod Upgrade w/ Soaking Period In Between
Maintenance Period 1 : Pod1 / Odds
Maintenance Period 2: Pod 1 / Evens
Maintenance Period 3: Pod 2 / Odds
Maintenance Period 4: Pod 2 / Evens
Maintenance Period n: Podn / Odds
Maintenance Period n+1: Podn / Evens
If Applications are only hosted on certain Pods and not stretched across pods then the first option works well. You can complete an upgrade with only two maintenance windows and allow for some time in between to validate everything. As you start to get more granular with your change control, the time its going to take to upgrade grows as you can see. You have to balance application availability impact w/ time invested for performing the upgrade. It's fully supported to run ACI fabrics in a mixed-version for a period of time, but I would try to limit this to less than a month if possible - Especially across major versions where new features are introduced.
Others can chime in with their experience.
Robert
