[new release] syndic (1.7.0)

[dinosaure]

RSS1, RSS2, Atom and OPML1 parsing

• Project page: https://github.com/Cumulus/Syndic
• Documentation: https://cumulus.github.io/Syndic/

CHANGES:

• Fix categories on RSS2 (@yawaramin, @dinosaure, Fix rss2 Cumulus/Syndic#87)

[yawaramin]

There are a couple of changes that break backward compatibility. Imho this should be released as version 2.0.0

[dinosaure]

My versioning policy (MAJOR.MINOR.PATCH) is to notify changes in implementation with the PATCH number. API changes (such as this one) affect the MINOR number, and changes that essentially involve reworking the library and a complete change to the API (as was recently the case with carton) are notified with MAJOR.

Thank you for your work, but the change made does not constitute a major change according to my criteria. It is also noted that reverse dependencies do not fail.

[yawaramin]

It is also noted that reverse dependencies do not fail.

That's good but it's possible for other projects to break. Eg I'm pretty sure this will break: https://github.com/cosmicboots/rss_reader/blob/ee793f3ee5d91abda916296e4fdd9373aadd85cc/lib/etl/etl.ml#L48

[shonfeder]

It is also noted that reverse dependencies do not fail.

That's good but it's possible for other projects to break. Eg I'm pretty sure this will break: https://github.com/cosmicboots/rss_reader/blob/ee793f3ee5d91abda916296e4fdd9373aadd85cc/lib/etl/etl.ml#L48

That project has no upper bounds, so it will get a build failure anyhow, and that will be more noticeable than a digit incrementing :D -- But you could open a PR to add an upper bound there (or better, update it to be compatible?).

IMO,

• packages which are not published in the opam-repo are outside of the purview of our primary concern, and they should not be a reason to block package publication.
• our policies do not dictate a semantics for version constraints. If you think this should be changed, an issue regarding the policy seems to me the appropriate place, rather than the PRs to publish particular packages.

All that said, the review of this package is much appreciated, as is discussion and notification of possible breaking changes!

[shonfeder]

The only test failure are on a dependencies (or in the case of Windows, an known ongoing issue with opam in the Windows CI there.

[yawaramin]

Just as a note, my intention with my original comment was not to block publication, only to recommend a version for this specific package (not for the entire opam repo). Obviously, I can't force anyone to follow my recommendations 😉

That project has no upper bounds, so it will get a build failure anyhow

Agreed, and my recommendation of SemVer would not prevent build failures anyway, it would just constrain them to major version updates which I believe most people expect from packaging systems.

[shonfeder]

my intention with my original comment was not to block publication, only to recommend a version for this specific package

Sorry for the poor choice of words! Thanks again for your time reviewing :)