Releasing ramda v0.28.2 on npm?

[eemeli]

The repo has a tag v0.28.2, but this does not appear to be released at least on npm. Is there a plan for doing so?

I'm interested, because this release appears to include #3270, which is needed to resolve lo1tuma/eslint-plugin-mocha#322.

[customcommander]

I somehow missed that release :/ Not sure what happened here as v0.28.1 doesn't exist either. There are ongoing discussions about typings perhaps it was done for that purpose (I didn't follow the thread so I'm just guessing)

Before we do anything can you try pulling from the repo just to confirm it does fix your issue?

npm i ramda/ramda#v0.28.2

However I've noticed that the package name has been changed to ramda-ts-self which is going to break a few things unfortunately.

Not sure we can publish this to NPM. @CrossEye @kedashoe ?

[CrossEye]

Yeah, I don't recall anything about that, and I definitely don't think we want to publish it with that name. I'm guessing you're right and that this has to do with the typing stuff. Is that right @kedashoe ?

[kedashoe]

the ramda-ts-self name should only be on the ts branch. If I've changed it somewhere else that messes with the master branch/normal release process please revert!

[customcommander]

the ramda-ts-self name should only be on the ts branch. If I've changed it somewhere else that messes with the master branch/normal release process please revert!

The package name change is still isolated to that branch but was there any reason for the v0.28.2 tag? It seems to have confused people that's all.

[kedashoe]

was there any reason for the v0.28.2 tag? It seems to have confused people that's all.

ah I see. I don't think it will be a problem with NPM right? It is a different package?

But it does seem here in github it's not ideal. I will look into using different tags of some sort going forward. And maybe can revert the one that I pushed up as well, doesn't matter from the ts side as it is just for testing.

[kedashoe]

OK I've deleted the tag. I'll start over from 0.1.0 and use ts in the version and tag somewhere to disambiguate.

[kedashoe]

I've released a new version of the ts stuff and attempted not to push any tags (ie instead of using "different" tags, I just won't tag the ts releases). If everything looks ok to yall, you can go ahead and release a new version of ramda proper.

[lo1tuma]

So is there any chance that the fix from #3270 will be released in a new patch-version? Now that node v18 has been released this seems to get more urgent.

[customcommander]

Hi all. Sorry for the radio silence lately. I started a new job and have busy weeks at the moment.

Fortunately that commit sits before two major breaking changes so in theory we could simply tag it. My question is how will this plays out with our custom release tool. I assume it works only with the head of a branch it runs in. If that's the case we need to revert those two breaking changes first.

It could be an option too: have a 1.0 release branch to isolate breaking changes so we can still have bug fixes landing on master safely.

@CrossEye: Any thoughts?

[CrossEye]

@customcommander:

There are never any apologies required around here for spending time away from Ramda. I'm the worst offender, by far. I'm going to be mostly unavailable at least until after this weekend, myself.

I think maybe that's the best idea for right now.