Currently we split our Deployment Packages by Month and Region. The purpose for splitting by region is to include only Asian/Pacific languages in our packages for sites in that region, only South American languages for sites in that region, etc. English is deployed everywhere just for safety. This helps reduce storage requirements on sites that are tight on space. This also has the assumption that a computer in Japan doesn't have a Brazilian language installed.
I was posting in another thread and someone had asked why we have our packages by month instead of by year. I really don't have an answer for that except that this structure was in place before I started at my current company. I do know there is a Microsoft Recommendation with SCCM 2007 to keep Deployment Packages under 500 updates. I make a few search folders for the past few years and exclude expired and superseded. I'm left with 352 updates for 2013, 541 for 2012, and 503 for 2011. This is likely because we have a huge environment mixing Server 2003, 2008, 2008 R2, XP, Windows 7, and now coming up with a few Server 2012/Windows 8. Are others running over the 500 update recommendation when using Yearly packages? If so, are people further splitting by product, or getting away from Yearly and moving to quarterly?
Finally, does anyone know if there is a difference between having a Deployment Package with 500 updates vs one with only 30 or so? (other than size). I would imagine the larger one would take longer for clients to process, but I'm unsure if it's noticeable. It would be good to understand if it's faster to process 1 package with 500 updates or 12 packages with ~42 updates. I heard somewhere that reporting is easier with Monthly deployment packages for compliance. Is that the case?