[RFC] Bump version number to 1.0 (or 27.0.0)

[razor-x]

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 (graphql/graphql-js#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 recompose 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 may be a desired set of issues to address to reach the 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 10k stars, recompose 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). Under semver, version numbers do not drive features, but are defined by what bug fixes and API changes are released in any version. Alternativly, following React and graphql, recomponse could release v27.0.0 instead (see links below).

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 (success):

• Follow Semantic Versioning, version 1 (RFC) avajs/ava#1637
• https://github.com/avajs/ava/releases/tag/v1.0.0-beta.1

graphql (success):

• https://medium.com/@leeb/graphql-js-preparing-for-v14-0-0-839f823c144e

Ramda (wip):

• Major version bump to 1.0 ramda/ramda#2337

[istarkov]

Just curious how version number affects your own workflow. Why we need to use some so so system like major minor patch, how to distinguish patch vs minor. Sometimes is even hard to detect is current change is major. As an example - flow definitions change, from one pov its just type improvements and does not affect at all users who doesnt use flow. For flow users its a major change. Same for dependencies etc. IMO its all just a words, any patch version could break your env, and major changes can have zero effect.
Having that yarn and npm are locking dependencies IMO all that things above are nothing ;-) so what is you real reason without all that links above?

[razor-x]

I had hoped I would not have to argue for the generally accepted value of following the semver spec. In the end it's not your or my single opinion on this that really matters, but the opinion of your wider user base. Probability suggests that the majority of them value adopting semver, especially considering many projects in the ecosystem take it seriously, e.g., react, redux, Next.js, (now) graphql, jest, etc.

Hopefully other users and contributors will make a case for (or against) semver so we can keep the discussion open and moving forward. For now, I will leave this gem: http://sentimentalversioning.org/

[istarkov]

You are right, I wanna add support for modern context, move rx components into own lib, and think we can change versions after.

[razor-x]

Good to hear. Hope to see a major version in the next release or two.

To answer some of your concerns, I would first recommend reading carefully the spec and it's FAQ, as I believe it will answer many of them better than I can: https://semver.org/. Here are my thoughts on a few though:

Sometimes is even hard to detect is current change is major. As an example - flow definitions change, from one pov its just type improvements and does not affect at all users who doesnt use flow. For flow users its a major change.

If it breaks the public API for anyone then it's a major version bump. If most users are unaffected they will look in the changelog and quickly see they are not affected. In your example, non-flow users would see that one breaking change and easily ignore it. (Types are an interesting example though as in principle types should define the public API and thus only change at the semver level as the API itself.)

Mistakes make it though. That's fine: we will never be perfect. The spec outlines what to do in those cases to reduce the impact on your users. See also https://semver.org/#what-do-i-do-if-i-accidentally-release-a-backwards-incompatible-change-as-a-minor-version

Same for dependencies etc. IMO its all just a words, any patch version could break your env, and major changes can have zero effect.

It's never going to be a perfect system, but the more packages that make a best effort to follow semver, the less chance users will be affected. This RFC is exactly to address that concern for this widely used package. See also https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

Having that yarn and npm are locking dependencies IMO all that things above are nothing

Users need to update the lockfiles for many reasons, and they will not have most dependencies of their dependencies (etc) in package.json, thus they rely on those packages using flexible version constraints and semver to ensure overall stability.

[jcrben]

note that following semantic versioning affects the decision calculus in whether to use this product (especially in businesses, e.g. my employer brightideainc) - it's best if we can reliably upgrade

[wuct]

I agree with that we should bump the version to 1.0. The potential blockers probably are #609 and #660.

[vire]

Any progress/blockers on this?

[shroomist]

subscribing to this

[dpikt]

Looking forward to this so Greenkeeper will stop bugging me about patches.

[zanerock]

My specific use case: we have a chain of React component libraries, with basic components feeding into ever more complex components. This currently goes through 3 links in the chain to get the final app. We use Rollup and exclude peer dependencies. I would like to specify recompose as peer dependency so it's not included in every library and just linked at the end. But specifying a specific version (which is effectively all we can do until recompose goes to 1.0) is an anti-pattern for peer dependencies as everytime recompose bumps a version, we would need to update it every peer dependency spec.

[razor-x]

Seems like the linked "blockers" have been stalled for a few months now. I still strongly support bumping the version to either v30.0.0 or v1.0.0 without delay (for example, you can make an announcement this week and release it next week).

This issue was opened when v0.27.0 was released. We are now on v0.30.0. I still see no reason any of those last versions could not have been > v1. Tear the band-aid off as they say 😄