Deprecate expandShorthands/createShorthands/create*Shorthand/expand*Shorthand

[oliverklee]

#510 (comment)

Expanding and creating the shorthand notation is out of scope for this library. So we should remove the functionality, make all the corresponding methods a no-op and mark them these methods as @deprecated #511 will be removed in version 10.

[JakeQZ]

We could provide a link in the readme to a tag for the last release which includes the functionality, to help anyone who wants to include it in their own project, and/or encourage someone to build it into a separate package.

[ziegenberg]

One deprecation at a time:

• [TASK] Deprecate DeclarationBlock::expandShorthands #558
• [TASK] Deprecate Document::createShorthands #567
• [TASK] Deprecate Document::expandShorthands #566
• [TASK] Deprecate DeclarationBlock::expandShorthands #568
• [TASK] Deprecate DeclarationBlock::createShorthands #569
• [TASK] Deprecate DeclarationBlock::expandBorderShorthand #570
• [TASK] Deprecate DeclarationBlock::expandDimensionsShorthand #571
• [TASK] Deprecate DeclarationBlock::expandFontShorthand #572
• [TASK] Deprecate DeclarationBlock::expandBackgroundShorthand #573
• [TASK] Deprecate DeclarationBlock::expandListStyleShorthand #574
• [TASK] Deprecate DeclarationBlock::createShorthandProperties #575
• [TASK] Deprecate DeclarationBlock::createBackgroundShorthand #576
• [TASK] Deprecate DeclarationBlock::createListStyleShorthand #577
• [TASK] Deprecate DeclarationBlock::createBorderShorthand #578
• [TASK] Deprecate DeclarationBlock::createDimensionsShorthand #579
• [TASK] Deprecate DeclarationBlock::createFontShorthand #580

[sabberworm]

@ziegenberg IMHO you could have put the deprecations into a single PR instead of doing a new PR for every single method. Thanks a lot for your contributions, though.

[oliverklee]

IMHO you could have put the deprecations into a single PR instead of doing a new PR for every single method.

@ziegenberg talked/wrote about this, and I requested them to be single PRs. This allows for smaller PRs and allows us to easily revert single things that haven't worked out.

[ziegenberg]

I surely would have put them into one PR. Would have been much easier and would require a lot less rebasing, namely 0.

That's another thing to put into the CONTRIBUTING.md, together with all other kinds of policies.

[sabberworm]

It seems @oliverklee and I disagree about what is an atomic change…

[sabberworm]

I guess a compromise would have been to make it a single PR but one commit for each change. That would have made them revertable without all the drawbacks.

[oliverklee]

Then we would have had a merge commit, and I find a linear history really helpful.

For cases like this, I'd be fine with having separate PRs for the deprecations and a follow-up PR to add the changelog entries. This would help avoid the merge conflicts and the need for a rebase. Would that be helpful for you, @ziegenberg?

[ziegenberg]

Then we would have had a merge commit, and I find a linear history really helpful.

For cases like this, I'd be fine with having separate PRs for the deprecations and a follow-up PR to add the changelog entries. This would help avoid the merge conflicts and the need for a rebase. Would that be helpful for you, @ziegenberg?

Yes, that would be helpful next time.

This time, Whether I rebase this pile of PRs or collect all changelog entries from every PR, package it into a new PR and adjust all PRs, it makes no difference in the work I have to do.

In either case, make it a policy and put it into CONTRIBUTING.md for others to follow.

[ziegenberg]

Can be closed now.

[oliverklee]

Thanks a lot, @ziegenberg! ❤️