Closed egil closed 1 year ago
Ps. I have completely forgotten how we update the changelog. Please advice and ill push an update.
In general looks good.
Regarding the question: Just edit
CHANGELOG.md
(https://github.com/AngleSharp/AngleSharp.Diffing/blob/devel/CHANGELOG.md). I see that There is a preview of0.18
out. I'd suggest to make this0.17.1
instead to keep parity with the used AngleSharp libraries.
I noticed that too. Not sure how that version number came to be though. Does our build script support making this 17.0.1 and pushing that out now that 1.8 is out?
I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.
It would be nice to keep diffings version aligned with anglesharp, but hopefully they can all be bumped to 1.0.x soon, anyway, so I would rather just push a new none-preview that includes all the changes we have in the pipeline.
I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.
You can just unpublish 0.18.x preview. Really these are just previews - so no worries here.
I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.
You can just unpublish 0.18.x preview. Really these are just previews - so no worries here.
as in go to nuget.org and click hide them?
as in go to nuget.org and click hide them?
Yeah I think that's what I did at least with some (really old) 1.0.0 preview packages of AngleSharp itself.
Types of Changes
Prerequisites
Please make sure you can check the following two boxes:
Contribution Type
What types of changes does your code introduce? Put an
x
in all the boxes that apply:Description
Suppose the user somehow manages to create two nodes, where one is considered unknown and thus has its node name in upper case, and the other node does not. In that case, they should still be regarded as equal, as long as their
NodeType
are identical andNodeName
is the same (case insensitive).Inspired by the question here: https://stackoverflow.com/questions/75335821/bunit-simple-markup-verification-for-path-tag
A simple example is this:
Let the control node be the
<path>
element found by parsing<svg><path></path></svg>
and select the first child. Let the test node be the result of parsing<path/>
. This will result in an IUnknownHtmlElement being returned.Then the element comparer should consider the control node and the test node equal.
Ps. PR also includes some housekeeping commits.