[CT-3302] [Feature] Versioned models should contain a changelog field

[joellabes]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

If I'm deciding whether to adopt a new version of a model, I want to see what I'm in for. It would be useful for model providers to add an explanation of what changed between two versions, but currently that would have to go into the description:

  - name: rpt_demographics_by_department
    description: My very important model with an exhaustive description. 
    columns:
      [...]
    versions:
      - v: 1
        columns:
          - include: all
            exclude:
              - cohort
              - breakdown_type
        tests:
          [...]
      - v: 2
        description: My very important model with an exhaustive description. In v2 of the model, the `org` column is replaced by `cohort` and `breakdown_type` columns. 
        tests:
          [...]

That's not ideal because new consumers don't care about changes from a version they've never used. And when there's already a long description there, we're tacking even more onto the end which people might not notice.

Let's split it out into its own place:

  - name: rpt_demographics_by_department
    description: My very important model with an exhaustive description. 
    columns:
      [...]
    versions:
      - v: 1
        columns:
          - include: all
            exclude:
              - cohort
              - breakdown_type
        tests:
          [...]
      - v: 2
        # you'll notice that description is missing now, because it can continue to inherit the normal one
        changelog: 
          - message: Data is now available for role types (Individual Contributor, Manager) in addition to the existing orgs.
            severity: informative
          - message: To prevent aggregates from being broken down into individually-identifiable groups, the `org` column is replaced by `cohort` and `breakdown_type` columns, to ensure employees can be only split by either org or role type, but not both.
            severity: breaking
          - message: Rounding errors in percentages no longer sum to >100%
            severity: informative
        tests:
          [...]

Describe alternatives you've considered

• Continuing to put it into the description.
• Allowing either a single string or an array of strings, instead of an array of objects containing message + severity.

Who will this benefit?

People considering adopting a new version of a model
It would be easier and tidier to consume in Explorer (thread)

Are you interested in contributing this feature?

Maybe, given some pointers.

Anything else?

No response

[dbeatty10]

@joellabes This is a super interesting idea to communicate changelogs, release notes, etc. in a formal manner that is targeted and structured.

Promoting this to a Discussion for further conversation.