Reverting: Adding height and width to elements that can contain embedded content

[frj]

This reverts the changes to add height and width to various element types.

#191

This change turned out not to be useful so its being removed to avoid unused clutter.

[JustinPinner]

👍 (if these definitely didn't end up in the published models)

[tonytw1]

In Thrift are you allowed to recycle a label like this?
Honestly don't know.

[frj]

Good spot tony: https://diwakergupta.github.io/thrift-missing-guide/

Don’t change the numeric tags for any existing fields.

[frj]

👍 (if these definitely didn't end up in the published models)

The content-api-model libs were published but the content-api-scala-client wasnt published with those models libs.

Lets discuss on monday.

[frj]

Apologies, I mixed up the order I created the new fields.

Width and height did actually make it out into the wild.

Im slightly nervous about making this change now, there does seem to be some danger around removing fields in this way.

As Tony pointed out, its important that the field ids are not reused: https://diwakergupta.github.io/thrift-missing-guide/

Non-required fields can be removed, as long as the tag number is not used again in your updated message type (it may be better to rename the field instead, perhaps adding the prefix "OBSOLETE_", so that future users of your .thrift can’t accidentally reuse the number).

The intention was to 'tidy up' the schema, and leaving around fields with "OBSOLETE_" or commented out fields doesn't feel very tidy.

Its entirely possible these fields will be useful again in the future.

Maybe the best option is just to remove the code that generates these fields out of CAPI, but leave these fields in the schema.

Does anyone have any opinions on this?

[tonytw1]

This looks like the correct way to deal with removal of optional fields.
Retire the label and never reuse it