[CT-2037] Parsing: model ‘deprecation_date’ attribute

[MichelleArk]

Parse deprecation_date: Optional[str], as configured in a model yaml property file. Should be available as a model node attribute in the manifest.

Validation

• deprecation_date should be a valid datetime format(potentially configurable at the project-level?) or a special ’never’/‘unplanned’ string value
• All versioned models with latest:false must declare a deprecation_date.
• Only versioned models can have a non-null deprecation_date

[jtcohen6]

potentially configurable at the project-level?

Yeah, this would be a vote in favor of implementing deprecation_date as a standard config (unlike version or latest).

Only versioned models can have a non-null deprecation_date

I don't think we need to enforce this. While all non-latest versioned models must be deprecated, I think a model could declare its own forthcoming deprecation, even if it's not versioned.

Taken together, I think there's a fair argument for deprecation_date as a config. It's definitely related to version/latest, conceptually and for certain validation steps, but users could also make use of it independently of model versioning.

[emmyoop]

Will we throw an error if we are past the deprecation date? #6870 mentions warnings if the date exists but it's unclear what happens after the date is in the past.

[MichelleArk]

Closing in favor of implementation issue: #7433