Don't Pin AngleSharp Version

[matthewDDennis]

Having made the correction for the Configuration constructor API change, pinning the AngleSharp Version only prevents users from updating to the latest AngleSharp.

It is no longer needed.

[304NotModified]

AngleSharp constantly introduces breaking changes, see #78, #76 , #68, #64 and #53

[matthewDDennis]

But the solution builds without error using AngleSharp 9.8.1. We are using both AngleSharp and HtmlSanitizer, so having HtmlSanitizer limit which version of AngleSharp is a deal breaker. I've clone the current HtmlSanitizer repo and updated the AngleSharp version in the 'Core' project to produce the Nuget package.

Since VS2015 'Core' projects can produce .NET 4.5.x compatible Nugets that also include the .NET Core compatible versions, why have two projects?

[304NotModified]

So the best solution IMO is to send a PR (to this repos) with the updated (and tested) AngleSharp.

Too bad history shows that not pinning AngleSharp is a bad idea.

[mganss]

I've updated to the latest AngleSharp release (0.9.8.1) but kept the pinning for now due to the reasons @304NotModified outlined above. AngleSharp seems to be "hiding" behind the 0.x status which voids all the benefits SemVer is supposed to have (except for the syntactical structure of the version number).

@matthewDDennis I've kept the .csproj because it loads and builds faster (plus it seems .csproj will come back anyway for .NET Core). There is no harm to it, is there?

[LunNova]

Is a stable release targeting AngleSharp 0.9.8.1 planned?

[mganss]

Yes, I've been wanting to do it for a while now, just didn't get around to it. Monday.

[CloudInnovationsDev]

how about a stable release targeting AngleSharp 0.9.9?

[mganss]

Released 3.4.156 targeting AngleSharp 0.9.9.

[CloudInnovationsDev]

that was very fast! thank you :)

[304NotModified]

PS there is a AngleSharp 0.10 planned. So no 1.0 yet

[ImrePyhvel]

Update: AngleSharp/AngleSharp#1041

AngleSharp 1.0 (as first stable base version for semVer) indeed still not coming and the Owner seems to hold it back for some undisclosed reason. "Documentation need work" won't be a breaking change, so that's hardly the real reason.

6+years in the making, semver likely will not happen in foreseeable future, if ever.

EDIT: I was proven wrong about the "future"-part.

[FlorianRappl]

Please don't post misinformation @ImrePyhvel. The referenced issue is about a 1.0, not about following semver. AngleSharp follows pre-1.0 semver (0.x.y) since a while (read the CHANGELOG). Just posting nonsense and not contributing is the poison that let's open-source suffer.

[ImrePyhvel]

I'm sorry if there was some miscommunication, but everything I said seems to be just observations and match the current state, by information visible to me. No poison intended. @FlorianRappl, in case you DO care to think along (in the calm non-poisonous constructive spirit of open-source):

The point of this and the linked AngleSharp task (and others similar ones) is hardly seeing the pretty curves of specific numbers 1.0, but knowing which versions are safe to (automatically) upgrade to and which ones may not. Not only by HtmlSanitizer, but everyone down the dependency tree needs to consider this for every version of Anglesharp released. In the IMHO de facto industry-standard semver-world, there are some guarantees for compatible projects starting from v1.0+. Other than that, hardly anyone cares if current version is called 0.17, 1.0, 17.8 or 158. Ofc, when I used the term semver , I do not mean just any possible imagined versioning semantics, but the very Semantic Versioning 2.0.0 specification from https://semver.org , which states explicitly:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

So, in essence, ALL semver benefits start from 1.0, and that is what OP, @304NotModified, myself, and other users were IMHO asking for. Not 1.0 per se, but some semantics to AngleSharp versions. SemVer (or other such guarantees) are a prerequisite for unpinning AngleSharp to some wider span of versions and reduce the cascading upgrade nuisance.

I'm glad to hear that Anglesharp actually IS following some versioning semantics, but I'm not familiar with the meaning of pre-1.0 semver (except the semver specification mentioned above, by which there are explicitly no guarantees for 0.X.Y compatibility), nor is it obvious to me what guarantees you are giving by this pre-1.0 semver for 0.X.Y versions, nor can I find any hint for AngleSharp custom versioning semantics or compatibility rules in mentioned CHANGELOG. Having a list of changes is good, but is not explicit which changes are breaking changes, and even if it were, N previous data points do not guarantee anything about future versions. Nor does AngleSharp state anything about versioning semantics in the intro page. It would be helpful and suffice if it did explain the semantics of versions and intended guarantees explicitly.

So, relax. Anglesharp DOES NOT have to adopt semver 2.0.0, if it has other plans (and timeline). I just gave my observations about the current state and the perceived outlook for this task, based on what I saw. I would not mind at all if Anglesharp contributors would address the need for clarity in this regard, turning my mentioned observations obsolete. When they do, this very task of unpinning AngleSharp would become unblocked + save time for many-many developers directly or transitively depending on AngleSharp.

[mganss]

@FlorianRappl Is the AngleSharp API sufficiently stable now so that we wouldn't run the risk of encountering issues like those mentioned above in #87 (comment) if we no longer pinned the AngleSharp version?

[ImrePyhvel]

Anglesharp is now v1.0.0: https://github.com/AngleSharp/AngleSharp/releases/tag/v1.0.0
Semver compatibility guarantees should apply and it should be safe to unpin to [1.0.0-2.0.0)?

[mganss]

There are two issues in 1.0.0 that cause tests to fail: AngleSharp/AngleSharp#1083 and AngleSharp/AngleSharp#1070
Ironically, AngleSharp/AngleSharp#1083 is caused by a breaking change in the public API 😄

[mganss]

AngleSharp 1.0.1 has been released and tests pass now. I'm still hesitant to unpin the AngleSharp dependency because of possible interaction issues with AngleSharp.Css which is still below 1.0. What does everyone think? @ImrePyhvel @304NotModified

[ImrePyhvel]

Latest version of Anglesharp.Css was tagged just yesterday and still depends on Angelsharp (>= 0.17.0 && < 0.18.0). If the author does not consider them compatible then no point in forcing it from consumer side.

Sry, was too eager to jump on it without checking Anglesharp.Css, let's wait for entire v1+ package.

[rekna1]

I hope this gets resolved! I have a dependency on a third party component for which there are no (or no good) alternatives. This component has a dependency on AngleSharp (>= 1.0.1) so I'm stuck in a scenario where there is no solution for me until HtmlSanitizer solves the issue !!