v0.29.0 released

[kedashoe]

Let me know if anyone notices any major issues with the release.

Release notes here. Please reply anything important I missed in the notes and I will update them.

Thank you to everyone for contributing, apologies it took so long to get a release out!

[sacrosanctic]

documentation no longer categorizes the functions (ie list, string, function, object), is this intended?

[adispring]

documentation no longer categorizes the functions (ie list, string, function, object), is this intended?

Thanks for your report. This is not intended, I've found what's wrong, and will make a PR (ramda/ramda.github.io#277) to fix it.

[Harris-Miller]

The function signatures are missing as well, the @sig in the block-comments

[kedashoe]

documentation no longer categorizes the functions (ie list, string, function, object), is this intended?

Thanks for your report. This is not intended, I've found what's wrong, and will make a PR (ramda/ramda.github.io#277) to fix it.

ty for the PR, merged and updated docs

The function signatures are missing as well, the @sig in the block-comments
Is this fixed now for you? Signatures seem to be there for me?

[kedashoe]

Looks like the repl is not using the latest version of ramda

[Harris-Miller]

@kedashoe I see the signatures again. Not sure why I didn't see them before, maybe something about that 277 MR made them work again

[adispring]

@kedashoe I see the signatures again. Not sure why I didn't see them before, maybe something about that 277 MR made them work again

Yes, the generating of sig, category and some other tags depend on R.propEq.

[Harris-Miller]

@kedashoe The "Install" section has a variety of old semver versions

Edit: ^^ don't mind the color difference, that's a Chrome Darkmode extension I use

[kedashoe]

@kedashoe The "Install" section has a variety of old semver versions

I don't know much about deno and nest, seems those versions are correct in that they are the latest versions of ramda there? Looks like those CDNs are updated, not sure how quickly/often they update. I don't believe we traditionally handle releasing on anything but NPM, maybe we should just remove these links?

[Harris-Miller]

I'm not familiar with ramda's release process. Are releases to all delivery networks not automated?

[mvangent]

Great stuff! Could you please consider using semver going forward? The parameter order for the propEq and pathEq have changed and it could have major implications on business logic. Many projects have automatic minor updates enabled.

I know this issue was raised in 2017 already, and you probably are all busy, yet it would be really great if such a widely used lib as ramda would adher to semantic versioning in the future.

[semmel]

@mvangent At least npm treats the 0.+ bump as breaking change

(Caret Ranges, e.g. ^1.0.0, ^0.1.0, ^0.0.1) allow changes that do not modify the left-most non-zero element in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

So with ramda: "^0.28.0" in my package.json I'll have to npm install ramda@latest to get to v0.29. npm install will still install v0.28.

I don't know if that's Semver compliant, but the process works.

From the psychological point of view I think Ramda has long deserved a non-zero major version number, at least v1, if not even a jump to v29.0.0.

[mvangent]

@semmel Yep, I get your point and if one is aware that minor version bumps can contain breaking api changes it is not a big deal and it can be managed with caret ranges.

But it would be nice to have breaking changes reflected in major version bumps to be in line with semantic versioning according to https://semver.org/. So if the minor version goes one step up it would mean that the api is still backward compatible which currently is not the case for ramda, however this semver standard is quite common across npm otherwise.

[tacomanator]

You're probably aware, but here is one issue for TypeScript users: @types/ramda is not yet in sync and therefore fixing instances of functions where the parameter order changed (e.g. propEq) will cause a type error when the compiler is checking for valid parameter names, where as not fixing it will obviously be a logic error.

[CrossEye]

Thank you @kedashoe!

I got downhearted by Mitre dragging me back into a vulnerability black hole after I'd spent so much effort on fighting Veracode on the same damned thing. (BTW: I reached out to Mitre again last week, and still get no response.) This left me too unenthused about getting back to Ramda (or really any other) FOSS work.

I promise I will be back. Maybe not for another month or two, but reasonably soon. It's good to see someone picking up the reins meanwhile.

[CrossEye]

In the meantime, if anyone has the energy to create an Upgrade Guide for this version, it would be useful.

[kedashoe]

In the meantime, if anyone has the energy to create an Upgrade Guide for this version, it would be useful.

Hey @CrossEye :)

I've included the upgrade notes on the release: https://github.com/ramda/ramda/releases/tag/v0.29.0

[adispring]

@CrossEye @kedashoe

I've just created an Upgrade Guide for this version, which includes more details.

[CrossEye]

Thanks, @kedashoe and @adispring! These notes look great.