Change Process Guidelines #684
Conversation
|
|
||
| ## Versions | ||
|
|
||
| The FOCUS specification is released periodically. For each release a version number is assigned. Version numbers at this time are not strictly representative of compatibility. The version number is used to identify the release and to provide a reference point for changes. |
| New use cases: | ||
| - Compare billed cost per subaccount to budget | ||
|
|
||
| New attributes: |
There was a problem hiding this comment.
I'm suggesting a change to how we organize the changes to group similar areas together so it's easier to identify use cases separately from column changes. I have not applied this everywhere. If others are good with this, I can apply everywhere in this PR or a separate one, if preferred.
There was a problem hiding this comment.
Yeah I think that would be a good add to structure the change log so that it is a little more organized.
| - `StringEncoding` metadata column definition property | ||
| - `StringMaxLength` metadata column definition property | ||
| New use cases: | ||
| - Compare billed cost per subaccount to budget |
There was a problem hiding this comment.
Where should use cases go? First to show that we're scenario-driven? After columns since they depend on the columns anyway? Or last so they can also span metadata?
There was a problem hiding this comment.
In the change log there would be an indication that we added a new use case to the supported use cases list. In the actual list the use case would be added.
There was a problem hiding this comment.
@ljadvey Curious to hear you weigh in here.
| - `StringEncoding` metadata column definition property | ||
| - `StringMaxLength` metadata column definition property | ||
| New use cases: | ||
| - Compare billed cost per subaccount to budget |
There was a problem hiding this comment.
Note to self: I need to show how we flag use cases that have been impacted by a change. I don't think this use case has been changed yet, tho.
…brary 643 - add use case template
| ### Addition of a New Feature or Column | ||
|
|
||
| When a new feature or column is introduced to the FOCUS specification, depending on the circumstances of the change, the support of the column may be initially optional. This is to allow for the adoption of a new feature or columne by prodivers that support it, without restricting other adopters from using newer versions of the specification. | ||
| - The feature or item addition is proposed, which, in addition to the proposed specification change, includes the appropriate indication as to the optionality of the feature or column. ??Do we require a future optionality is solidified version?? |
There was a problem hiding this comment.
Removal indication of optionality just say it is a new thing.
No description provided.