Road to 1.0 #3397
Replies: 6 comments 4 replies
-
I reckon I'm on board with most of that, but do we need any of it for 1.0? For me it kinda feels like 1.0 should be ramda as we know it. Then we can get to things like integrated types, es6, releasing to other js platforms, etc. |
Beta Was this translation helpful? Give feedback.
-
I'm just a humble observer but most of the work to decide what to put inside 1.0 was done one year (or two?) ago by @customcommander. If I don't make mistakes, issues tagged with "1.0 discussion" were postponed after the 1.0 release. I couldn't find the discussion, but there was some sort of roadmap to 1.0 which was in short: let's release it asap. |
Beta Was this translation helpful? Give feedback.
-
Reviving this discussion... @CrossEye @kedashoe I never found the time to follow up on the line items I wrote originally, but I have been hard at work maintaining ramda/types. And the recent In addition to my original post, this discussion On becoming Ramda 1.0 from a year before this one, the 1.0 discussion labeled issues, this recent comment about getting to 1.0, I've got a laundry list of small items in my head that I need to get written down here to discuss, eg how to address fixing releasing to deno, integrating ramda/types directly into ramda/ramda, and a faster release cycle to help address higher priority things like Fix: cross-version placeholder support released fast (seriously that issue is hugely breaking under the right circumstances), just to name a few. How would the core team feel about developing a formal Roadmap? Utilizing Github Projects, or an alternative, and possibly doing a once-a-month/quarterly Zoom meeting of Owners/Core-Contributors to discuss, as well as act as a steering commit of sorts. (I've been thinking of also building a survey to solicit feedback from ramda users to help kick that off). This would be especially important for issues like continuing to support the I would like to bring up the personal concern I have over the continued adoption of Let me know how everyone feels about this idea. Any and all feedback welcome. How would the core team feel about developing a formal Roadmap? |
Beta Was this translation helpful? Give feedback.
-
Another issue raised asking for this as well: #3468 |
Beta Was this translation helpful? Give feedback.
-
I personally do not feel like I have time currently to commit to a formal roadmap. I am doing my best to keep the lights on and help move PRs along. The work you are doing on the typescript side is fantastic. I would be fine committing to any sort of release schedule, I try to maintain the upgrade guide as we go and cutting a release is easy and has gone smoothly recently. |
Beta Was this translation helpful? Give feedback.
-
Yeah just dedicating time to I just know that for ~10mil weekly npm downloads, we gotta make some improvements, especially around breaking changes |
Beta Was this translation helpful? Give feedback.
-
Preface
Recent discussions in an breaking MR led me to take a look at the state of
ramda
and has led me to want to start a discussion on what the "Road to 1.0" should look likeOut of the last four releases, while 0.26.0, 0.27.0, and 0.28.0 did have breaking changes, they were only for the removal of functions that were deprecated in the previous release. 0.29.0 however, had 2 signature changes. While the rules of semver do dictate that for a major release zero breaking changes are acceptable for minor releases, continuing to do
0.x
releases for a 9-year-old package at ~10 million downloads a week is becoming problematic. The default carrot ranges fornpm i
will install the latest version, regardless of the current semver range specified, which would lead to unexpected API changes. Tools like depend-a-bot and renovate-bot (to my knowledge) don't treat0.x
minors as breaking without custom configuration.So I started to think about what should be done to get to 1.0 and would like to begin a discussion about it
Disclaimer
I, @Harris-Miller, have only recently begun contributing to
ramda
, particularly for typescript development (see ramda/types). Recent paradigm shifts in front-end architecture, coding style, and state management tools that promote/require immutability, coupled with arrow functions, object/array spread and restructuring, and js bundlers' tree-shaking ability have all led a shift towards FP style javascript and away from classes ever since the release of ES6. I have pushed my peers to adopt FP style javascript and useramda
overlodash
. I've been able to demonstrate howramda
truly shines as "A practical functional library for JavaScript". The 2 largest pushback that I've gotten from my peers is the current lack of library support (long times between releases, very old/stale PRs, etc) and poor typescript support. The improvement of typescript support is already a task I have taken on, and so I have a vested interest in the success oframda
. And I believe the time is right to invest in that successSuggestions
WIP. Keeping this simple for now with just bullet point suggestions. Goal for right now is to gather feedback. Will update as replies come in
Repo and CI/CD
CONTRIBUTING
with strict rules concerning PRseslint
semantic-release style)develop
branch that will already release on npmnext
tag,main
branch onlatest
tagpackage.json
dependenciesCode, Issues, and PRs
1.0
.d.ts
files)@types/ramda
andtypes-ramda
noop
,debounce
/throttle
lodash
for these thingsDocumentation
String
is generally used to represent object keys, other times it isIdx = String | Int | Symbol
, orIdx = String | Int
{k: v}
vs{s: a}
list
vsxs
vsiterable
,key
vsprop
vsparam
,val
vsx
Functor
,Filterable
,Applicative
,Traversable
TypeRep
?Ramda-Fantasy
andMaybe
type Maybe<T> = T | undefined
What else?
Beta Was this translation helpful? Give feedback.
All reactions