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

[oliverklee]

https://github.com/MyIntervals/PHP-CSS-Parser/issues/510#issuecomment-1972628778

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 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:

• [x] #558
• [x] #567
• [x] #566
• [x] ~#568~
• [x] #569
• [x] #570
• [x] #571
• [x] #572
• [x] #573
• [x] #574
• [x] #575
• [x] #576
• [x] #577
• [x] #578
• [x] #579
• [x] #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! ❤️