TypelevelSiteSettings - deprecate top level color properties in favor of a nested object

[jenshalm]

Previously the color properties were all individual top level properties, drowning out the most relevant API elements. Secondly, their naming reflected the actual color, not their usage, which means that any changes in look & feel would lead to the need for new deprecations to avoid misleading names.

This PR moves all top level color properties into a new nested object colors and renames them so that they reflect their usage. The existing properties are all deprecated.

A possible change I would recommend, but did not do in this first version of the PR in case you want to be very conservative about it: I checked within the Typelevel organization, and not a single color property is used anywhere. So there is an option to remove these properties right away. In case you'd prefer that, too, I'll update the PR.

[j-mie6]

I'd definitely prefer it if the original colour names were kept as comments on the definition sites: that way it's easier to remember what they actually look like.

I'd also be in favour of keeping them as private variables, alternatively.

[jenshalm]

I'd definitely prefer it if the original colour names were kept as comments on the definition sites: that way it's easier to remember what they actually look like.

I'd also be in favour of keeping them as private variables, alternatively.

Sure, we can add comments, we can make the colors object private, we can even do both (e.g. comments are for maintainers). I really don't mind either way, so you can just make a call here.

What about the deprecated properties themselves? Do you want to keep them for now despite nobody using them?

[armanbilge]

Do you want to keep them for now despite nobody using them?

@j-mie6 I think you added them in #573, was there a reason you made them public?

I lean towards deprecation before removing esp. if it's not creating maintenance burden. But if there really is little use for them then I guess it would be fine.

[j-mie6]

Just in case anybody wanted to use them... I'm happy for them to be privatised. If nobody is using them, doesn't seem like a big deal

[jenshalm]

I pushed a commit that makes the colors object private. There are pros and cons for this and it seems you lean towards making them private.

I also kept the deprecated properties and just adjusted the deprecation messages. I believe nobody would notice if we'd delete them right away, but at the same time the maintenance cost of keeping them is so minimal that it's also fine. Just remember to delete them for 0.8.

[j-mie6]

Nobody is using them that we know of, so I'm totally in favour of just removing instead of deprecating. We're just a build system after all, and this is a major bump

[jenshalm]

Nobody is using them that we know of, so I'm totally in favour of just removing instead of deprecating. We're just a build system after all, and this is a major bump

I agree, but I thought @armanbilge was favouring to keep them?

[armanbilge]

Thanks both, this is fine for now. If we receive feedback then we can revisit visibility.

the color properties were all individual top level properties, drowning out the most relevant API elements

This is definitely sub-optimal. Something we can consider doing in the 0.7.x series after sufficient deprecation period is making them source-private but still public binary.