0.3.0 changelog#172
Conversation
|
@T0mstone I reordered what you suggested, and more. Tell me what you think. |
When deprecating a name in favor of another, we generally list the new name as part of the additions as well.
| - `supset.equiv`: ⫆ | ||
| - `subset.equiv`: ⫅ | ||
| - `supset.nequiv`: ⫌ | ||
| - `subset.nequiv`: ⫋ | ||
| - `subset.plus`: ⪿ | ||
| - `supset.tilde`: ⫈ | ||
| - `subset.tilde`: ⫇ | ||
| - `subset.times`: ⫁ | ||
| - `supset.approx`: ⫊ | ||
| - `supset.closed`: ⫐ | ||
| - `supset.closed.eq`: ⫒ | ||
| - `subset.approx`: ⫉ | ||
| - `supset.eq.dot`: ⫄ | ||
| - `supset.equiv`: ⫆ | ||
| - `supset.nequiv`: ⫌ | ||
| - `subset.eq.dot`: ⫃ | ||
| - `supset.plus`: ⫀ | ||
| - `supset.tilde`: ⫈ | ||
| - `subset.plus`: ⪿ | ||
| - `supset.times`: ⫂ |
There was a problem hiding this comment.
I think these should be grouped by supset/subset first. All other changelog entries also do it that way.
There was a problem hiding this comment.
I don't think this is inconsistent: we first list all new .closed variants, then all new .equiv variant, then all new .nequiv variants... And every time, we list supset before subset.
There was a problem hiding this comment.
But compare this to the arrow variants from 0.2.0: There, all arrow.r variants come before all arrow.l variants and so on. (Actually, with the exception of arrow.l.open, that seems to have been an oversight)
Similarly, the plus.o variants are all grouped together, and the times.o ones as well; We don't have plus.o, times.o, plus.o.big, times.o.big, plus.o.l, times.o.l, ...
In the same vein, I would have expected the supset and subset variants to be each grouped together, with the apparent exception that the closed symbols are listed separately because they form a more cohesive group like that (tho personally I would actually prefer them to just be grouped according to the base symbol, but I can accept this exception).
2 participants
This reorganizes the existing changelog entries in a way that is hopefully easier to read quickly.