Ramda: Major version bump to 1.0

[Siilwyn]

After seeing methods being deprecated and reading a bunch of closed issues on plans for version 1.0 I think this is a case of what Germans would call Hauptversionsnummernerhöhungsangst. The fear of a major bump. As Stephan Bönnemann (who is arguing hard for semver and did talks on the subject), loosely quoted:

Version numbers should be used to avoid dependency hell... There's no reason for keeping the version number low, expect for marketing or maybe emotional attachment to versions. There's this concept in our mind that the version number has something to say about the project or the process or the stability and all of this is wrong... People believe something incredible existing is happening when a major/breaking version is released... Leave your emotions out of this.

Please consider following semver, it doesn't mean the project is suddenly 'done' or has changed. It just gives users context about the change and reliability that patch and minor changes won't break their code base. Please consider this.

[polytypic]

My Partial Lenses library is already at version 12 (there is already version 13 in the works), because I have continued to improve the semantics and increased the major version whenever something has changed in a backward incompatible manner even if the changes are unlikely to affect any users. (Of course, there have been on average more than 10 releases per major version.)

I highly recommend:

• To release 1.0.0.
• To make feature releases more frequent.
• To make releases with deprecations as early as possible and to add e.g. console.warn statements to deprecated functions that are run once in development builds when such functions are called.

[CrossEye]

@Siilwyn :
I've been wanting to get to 1.0 for far too long. I agree that we should do this.

I think this will still take a fair bit of work, given how many open issues we have. But it's worth doing, and I will try to come up with a reasonable means of getting there in the next few days.

@polytypic:

I agree with your points, except for the console.warn. Ramda scrupulously avoids side-effects.

[buzzdecafe]

"Hauptversionsnummernerhöhungsangst" is a fantastic word

[Siilwyn]

@CrossEye thank you for your detailed & fast reply. I'm looking forward to it!

[CrossEye]

I dangled a participle in this:

I will try to come up with a reasonable means of getting there in the next few days.

That should really read

In the next few days I will try to come up with a reasonable means of getting there.

:wink:

[CrossEye]

We have started this process by having the core team begin to triage the huge list of open issues/prs. We'll figure out the next steps when we see how big the remaining list is.

[Siilwyn]

Sounds good, I see 170 issues with almost no labels, that's a tough job.

[CrossEye]

It was closer to 200 eighteen hours ago!

[CrossEye]

Just to keep everyone informed, the core team has created a forum for their own discussions about this list. I'm hoping that in two weeks or so we can come back with a draft plan, including a roadmap for 1.0, 2.0 and beyond. At that point we're going to ask for feedback from the wider community, and try to create a full plan.

So if it's quiet here for a little bit, don't worry: it's not quiet everywhere.

[abritinthebay]

Curious as to where this work is at. Are any issues good to help contribute on?

[CrossEye]

I'm afraid that effort died off. I meanwhile went through some health issues and job changes, and have not yet tried to get it back on track. I'm feeling better now and settled into a new job, so I thought I'd be trying this again in the next few weeks.

[abritinthebay]

Glad you're feeling better! Always take care of yourself.

Would love to help, so will be be keeping an eye on the issues/prs for anything I can contribute.

[razor-x]

Just checking in as well. I'd like to propose the same thing I've seen or introduced with other large-community projects struggling to commit version 1 long after they have already "implicitly" done so without properly supporting semver.

---

I'd like to quote the argument directly from this post on a different project (https://github.com/graphql/graphql-js/issues/1005):

I think it's time to move to 1.0+ versioning so that we can actually use the version number to transmit meaningful semantic information (ie. that a "major" version bump is a compatibility-breaking change). Our current version numbers (of the form v0.x.y) transmit basically nothing, because:

Major version zero (0.y.z) is for initial development. Anything may change at any time.

This entry from the Semver FAQ is also helpful:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

I think all of those apply to this package, so let's do it with the next release.

I'm specifically making the argument that it's long overdue for Ramda to release v1 so the version number can transmit meaningful semantic information since if you have a stable API on which users have come to depend, you should be 1.0.0.

I realize there is a 1.0.0 goal, but there is no public roadmap for that release (2 week, 2 months or 2 years out?). In the meantime, with over 11k stars, Ramda is being used by a large user base who depend on a stable API to build production applications. Waiting to close all "major" features before v1 is a race that you may never win on a project this size..

I propose moving to 1.0.0 as soon as possible (next patch or minor bump should be v1). Move all 1.0 and 2.0 roadmap items to something meaningful and unattached to a version number. Under semver, version numbers do not drive features, but are defined by what bug fixes and API changes are released in any version.

Users, please give feedback here if this is important to you, and maintainers, please explain why this should be delayed any longer. Thanks.

---

Here is relevant discussions supporting such an initiative.

React (leading supporting case study):

• https://reactjs.org/blog/2016/02/19/new-versioning-scheme.html#what-happened-to-100

Ava (recent success):

• https://github.com/avajs/ava/issues/1637
• https://github.com/avajs/ava/releases/tag/v1.0.0-beta.1

graphql (wip):

• https://github.com/graphql/graphql-js/issues/1005

[Siilwyn]

Wow, thank you for your reply @razor-x this is exactly what I was thinking (and still am) when I opened this issue. Couldn't word it any better.

[abritinthebay]

110% behind this

[razor-x]

@CrossEye Hope you are doing well.

Has the core team made a decision here? The current proposal is to simply release v1.0.0 whenever the next version is released off master.

That will help the large community of people using this project rely on semver support and free up the team to plan fixes and features according to semver without any more pressure to complete some arbitrary set of work for v1.

[CrossEye]

The core team hasn't really discussed this. I am planning on a release next weekend of v0.26. I would like one more release a month after that to clear up some outstanding issues, and then release 1.0 a month later. I really want to get to work on 2.0, but I think that will involve greater changes. If nothing else, I want to stop worrying about ES3 compatibility, and embrace ES6+.

[razor-x]

@CrossEye Two months is a bit longer then I was hoping for, but I'm happy as long as there is a commitment to that release window and not a moving target 👍

[CrossEye]

Everything's a moving target around here. But I'll do my best.

[razor-x]

@CrossEye just checking in here as two months have come and gone with no movement. Is there a clear plan to version 1 with a taget date? If not then I strongly recommend just pulling the bandage off and making whatever the next version bump is 1.0.0.

[wojpawlik]

With #2589 merged, what's the plan for 1.0?

My suggestion would be to release 0.26 (maybe after merging #2603, #2591 and other older PRs which still work on 0.12) and start working on 1.0, which'd be a possibly breaking update.

[CrossEye]

Such was my plan many months ago. I fell down on the job. I would like to go that route again.

[atassis]

Hi. I have read through the whole discussion and didn't find any worth reasoning not to bump up to 1.0 and move everything behind "1.0 discussion" label to 2.0. It should be an easy step, but it takes right now nearly 10 months just to discuss this. It is always better to choose easier road, which is bumping up the major version without any other changes is.

[wojpawlik]

I'm just worried that the team may be hesitant to bump to 2.0 right after 1.0 bump; I've already started working on multiple major changes, some of them are breaking.

[wojpawlik]

Please make a list of pull requests (and maybe issues) that should be resolved before 0.26,
so there's a clearly defined goal that can be worked towards and eventually achieved.

[CrossEye]

While I think that's a good idea, I won't have any time for that in the next two days. If anyone wants to start a list, feel free.

[PutziSan]

Hi, is there now a more precise timetable for how and, most importantly, when to move forward?

Fixes for issues like https://github.com/ramda/ramda/issues/2375 haven't been released for almost a year which is not optimal. It's okay if it's too time-consuming to maintain this library at shorter intervals, but then I would consider realizing my business-critical projects with another library.

[wojpawlik]

((🔔 )) Release when?

ESM is patched up, I haven't seen any serious issues opened recently, all the tests still pass on v0.12.18.

[CrossEye]

I'm building release notes right now for v0.26. Then I think we need a week or two of triage of open issues, and maybe two more weeks to fix whatever is decided during that. I'm hoping to have 1.0 out right after that, ideally by the first of the year.

[IgnusG]

@CrossEye will ramda follow semantic versioning after v1?

[CrossEye]

@IgnusG: That's the plan. The majority of the core team is inexperienced in managing a popular open source project, but we will do our best to comply.

[foxbunny]

@CrossEye The majority of open-source projects are doing a rather poor job of it, too. You guys are doing way better than most projects out there. :)

[CrossEye]

@foxbunny: thanks for the kind words. I've used libraries that have been magnificently maintained, and others that have been mostly abandoned. Ramda is nowhere near the former, but that's where we want to be. I hope we're not too close to the latter.

[razor-x]

@CrossEye Just checking up on this again for a new update. Really hoping we can see the Ramda major version bump this month.

If 1.0 still seems intimidating, you can always follow the examples of other industry leaders and release Ramda v27.0.0 as the next version.

• GraphQL: https://medium.com/@leeb/graphql-js-preparing-for-v14-0-0-839f823c144e
• React: https://reactjs.org/blog/2016/02/19/new-versioning-scheme.html

You can follow the same development cycle the project is used to, the only change being you would only need to release v28.0.0 if you introduce breaking changes. The extra version number will let you clearly communicate to your users when you will be deprecating and removing features. A common pattern is to introduce deprecations in a minor version number and then remove them in the next major version number.

Here are some objective stats to put things in perspective:

• This issue was originally opened over 1.5 years ago.
• The last official update was in November for a major release in January this year.
• That was over 5 months ago and January 1 was over 4 months ago.

And I'd like to echo the quote from the original submitter

Version numbers should be used to avoid dependency hell... There's no reason for keeping the version number low, expect for marketing or maybe emotional attachment to versions. There's this concept in our mind that the version number has something to say about the project or the process or the stability and all of this is wrong... People believe something incredible existing is happening when a major/breaking version is released... Leave your emotions out of this.

[Siilwyn]

Is anything currently preventing the version bump @CrossEye?

[kyeotic]

@CrossEye please consider that this issue is more than vanity. @razor-x has already laid out an excellent case. In addition to the communication power of version _changes_ there is also a negative communication for version numbers in the _0.x.y_ range; many developers (possibly unfairly) assume that anything prior to 1.0 is "not ready for production". Ramda is clearly ready for produciton, and has long ago reached stability.

You don't need any breaking changes, or even new features, to make 1.0 your next release. You can just say "its time" and release the current version as 1.0. It would be very valuable to the community.

[denkristoffer]

It looks like a v0.27 release is planned, can we cut that as 1.0 or 27.0 instead? Please. The 0.x.y. scheme doesn't play well at all with common package.json dependency versioning using the caret.

[razor-x]

Going to tag @CrossEye again here as he mentioned he was missing the messages in the last thread, so maybe similar thing here.

Please though, it's time. This issue just passed it's second birthday 🎂 and Ramda is over 5 years old (congrats!).

[wojpawlik]

Ramda will eventually become obsolete if it doesn't support Map and other modern types. Please drop support for at least

[conartist6]

@GingerPlusPlus I'm just passing through. If you want support for Map and modern types, why not take a look at iter-tools?

[semmel]

@GingerPlusPlus @conartist6 On the topic of modern collections imlazy also looks promising. Has anyone experiences with it?

[conartist6]

@semmel Thanks for that pointing that out, I hadn't seen it. I try to keep up with what's out there so that I can borrow the best ideas for iter-tools.

[Siilwyn]

This issue has been automatically closed because it has not had recent activity.