Why wouldn’t ETs w/ different schedules for different target groups work?
This is probably what I'm going to go with but think about this:
X changes from 0.9 to 1.0
ET1 - Deploy X to Group DEV on Day 1
X changes from 1.0 to 1.1
ET2 - Deploy X to Group PROD on Day 2
ET3 - Deploy X to Group PROD-OTHER on Day 3
ET2 and ET3 will deploy 1.1 to PROD and PROD_OTHER before 1.1 goes to DEV. Trying to avoid this situation in case changes in 1.1 blow up servers. Would rather blow up DEV before PROD
X .9 to 1.0
Deploy 1.0 to DEV
X 1.0 to 1.1
Deploy 1.1 to DEV
Deploy 1.0 to PROD
X 1.1 to 1.2
Deploy 1.2 to DEV
Deploy 1.1 to PROD
Agree it could work like that if BL had version mgmt and there was a way to condition ET to phase deploy the version per a condition rule set.
What we're going to end up doing is
ET1 Dev Region 1 - Day 1 Midnight - Deploy X current
ET2 Prod Region 1 - Day 1 Noon - Deploy X current
ET3 Dev Region 2 - Day 2 Midnight - Deploy X current
ET4 Prod Region 2 - Day 2 Noon - Deploy X current
This way we limit blow up exposure to a region regardless of when a change to X is made.
Why would version management matter ?
It doesn't really except for being able to roll back to a previous version of content.
I’m still not clear why that would matter.
You have one job for each version…
In a perfect world Admins would create a new version every time they updated content and/or batch jobs, that is not always the case, hence the *want* for built-in in version mgmt. At any rate I'm more concerned with phased scheduled deployments. Just going to implement the 4 ET method and try to build on it overtime
If you have a single package object per version it should be easy. I mean, it would be neat if you could have a package that contained multiple versions of something and you just have a flag to pass from the job (you can kind of do this now actually, but your package may get huge) and only that version gets copied and installed on the target.