Stable version and changelog? about remeda

[JeffBeltran]

When i first grok a tool, if it's not v1 i will typically skip over it unless the project i want it for is a hobby one. There are exceptions to this rule, axios, but even those annoys me. Most of our tooling leans into semver to keep a simple standards of

1. This update is gonna break stuff (major)
2. This update added new things (minor)
3. This update fixed a bug (patch)
4. This update could be any of the above or im still working on it (anything under v1 version)

IMO, Given the length of time this project has been active it's time to move it out of the "beta/alpha" stage and get it to SemVer so we can quickly know if/when we should be updating the package.

Here is a really good article that that does a much better job articulating this: https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2

[vladimiry]

I'd prefer the package moves to v1+ versioning as when I run yarn upgrade-interactive --latest and see red items I would normally go to package's changelog and review the breaking changes. Currently that command highlights "remeda" updates in red more often than actually needed.

[0x80]

Not sure if it matters to many developers but to me, version 0.0.30 signals that the project is still in its infancy. There must have been many features added over the years so I would expect the version to be 0.30.0 instead.

From what I gather the project is quite mature, so maybe a 1.0 release could help adoption.

[0x80]

Yes of course a version string does not give any guarantees and can be used however you like, but semantic versioning is what developers and systems expect and I don't see the advantages of using it differently.

Sticking at a minor version like Nginx did is very common and makes a lot of sense within semantic versioning, because then you can still introduce breaking changes before you feel like you've reached 1.0.

But there is no rule that 1.0 should be very a stable release. Other projects use 1.0 as their first public release, even though the API is not very mature at all, and that is also fine. Both approaches work and people (or systems like NPM) know what to expect from them.

But by only incrementing the patch/bug part of the semantic version, like was done in Remeda, a library consumer can never know how to interpret the new version. Because major+minor+bugfixes are all crammed into the same number. I don't see how that is helping anyone.

With Nginx at least you could expect a change from 0.12 to 0.13 to break things, and assume that it would be fine to upgrade from 0.12.0 to 0.12.5.

If Remeda doesn't feel like it's ready to release 1.0 yet, I would suggest to release 0.1.0 and start incrementing the minor version whenever new features are added or when breaking changes are introduced.

[dartess]

It seems that this can also be closed? @TkDodo

[TkDodo]

I would love to get changesets or something similar set up, but I'm lacking the experience to do so. For now, I've started writing manual release notes when releases are made, see the releases page: https://github.com/remeda/remeda/releases

regarding stable version: I honestly haven't seen us doing breaking changes in the last year or so, and I don't see why we would - the functions are pretty stable.

Unless I'm missing something, I think we could release the latest changes as v1. What do you think @lstkz ?

[vladimiry]

I honestly haven't seen us doing breaking changes in the last year or so, and I don't see why we would - the functions are pretty stable.

No blaming of something, but it's not really so.

Unless I'm missing something, I think we could release the latest changes as v1.

v0.0.29 is broken by the way.

[TkDodo]

No blaming of something, but it's not really so.

i guess i missed it then. Been using it for 2 years and no upgrade has shown any issues.

v0.0.29 is broken by the way.

a type issue for class usages isn’t exactly „broken“, but the fix is merged already and the question was more if it should become 0.0.30 or 1.0.0 :)

[vladimiry]

i guess i missed it then. Been using it for 2 years and no upgrade has shown any issues.

I was not exactly correct since #107 and #138 were not caught by automated tests bugs but not explicitly introduced breaking changes.

the question was more if it should become 0.0.30 or 1.0.0 :)

v1 looks fine for me as the functionality looks settled. Would appreciate the changelist (preferably on releases page but individual markdown page also works).

[TkDodo]

Yes I think bugs can happen to the best of us. I was more referring to intentional breaking api changes :)

[TkDodo]

published as 0.0.30 for now

[Bessonov]

From my point of view, the version doesn't matter. It doesn't tell anything about maturity, features or about whatever. For example, nginx stuck around 10 years 0.x and, well, it was rock stable from day I used it (~2008). Not without bug, but in very professional hands of Igor, Maxim and co. Other projects rush to 1.0 and then change everything in 2.0, then again in 3.0 and still very unstable.

Said that, I have no stakes about versioning and sure that 1.0 would help people who look at x.y to decide... but I'm not sure that it's right point to do that yet.

[JeffBeltran]

I'd prefer the package moves to v1+ versioning as when I run yarn upgrade-interactive --latest and see red items I would normally go to package's changelog and review the breaking changes.

Legit the same reason i posted this lol

[vlad-yakovlev]

First I've added this task to "roadmaps" but then understood that this issue could be resolved by #185:

• stable version – ✅
• changelog - ✅ (in github releases)