Releases v0.14.4 and v0.14.5

[PawelLipski]

Apparently, this library is lagging behind circe (and also circe-generic)... which means that for the sake of Scala Steward, we need to split the versions b/w this library and circe. Is it intentional? 🤔

[ComFreek]

Dear maintainers, any updates? :smile:

[awilliamsOM1]

I just put up two PRs to upgrade the circe versions. Hopefully the maintainers will accept the PRs and release new versions of circe-generic-extras

[zarthross]

We've added a table to the readme to help with this confusion, please reference this link https://github.com/circe/circe-generic-extras/blob/main/README.md#versioning

[awilliamsOM1]

I don't this this issues should be closed. I understand the versioning of circe-generic-extras is not intended to match the circe versions. That is fine. However it is important to update the circe versions in this library when new version of circe are released. For organizations with strict building turned on, circe cannot be upgraded to the latest version (0.14.6) because we also need circe-generic-extras which is still using circe 0.14.3.

My organization is trying to resolve a critical CVE vulnerability, but that requires upgrading circe, but we can't because circe-generic-extras hasn't released a version with circe 0.14.6. As a result our strict builds fail.

Two PRs have been put up that would solve this issue. I put up one and ScalaSteward put up one. https://github.com/circe/circe-generic-extras/pull/312

I am not trying to force maintainers to keep the version of circe-generic-extras synced with circe. But I would like to emphasized the importance of releasing circe-generic-extras with updated versions of circe dependancies when they become available.

[zarthross]

@awilliamsOM1 Are you saying that your builds disallow any evictions? Because that seems unreasonable in an open source ecosystem. If we are forced to release all 20 other circe projects every time core is released that would be very time consuming, we might as well have a mono-repo of all projects... and that's just not tenable.

Every time a new cats version patch version is released, do you expect every downstream project to release a new version? The entire reason we use projects like mima and version-scheme-enforcer is to ensure that patch releases and minor releases are binary compatible with each other... and if you are still worried about binary compatibility projects sbt-missingln exist to solve that problem.

[chedim]

Every time a new cats version patch version is released, do you expect every downstream project to release a new version?

After reading the previous comments I feel like this was not the issue. The issue, it looks to me, was that this project's latest version contains a known vulnerability through dependency and yes, in such a scenario every project should release an updated version that contains updated dependency without discovered vulnerabilities. And, IMHO, that should be a critical priority item.

[zarthross]

@chedim I'm not aware of what CVE involving circe or it's dependencies the previous comments are about. The only CVE of a dependency of which I'm aware is for circe-yaml, which has been addressed in circe-yaml which is NOT a dependency here.

If there was a CVE in circe core and we release an update I would agree that we should release what we can down stream. However it is still the end users own responsibility to update their own dependencies, transitive or otherwise, if there is an open CVE. There are dependabot tools and other things to help identify those. Tools like sbt-explicit-dependencies can also help.

This is open source, we volunteer our time... I can't release all 20 or so other circe projects every time the core is updated just to satisfy the strict build requirements of one business unit I have nothing to do with.