RFC: Release v1

[mlms13]

(In an attempt to also solve #329, I'm going to model this ticket after the same RFC approach that we're adopting at work.)

Overview

Relude has been relatively stable for the past several years. We've introduced very few breaking changes, and we've maintained compatibility with BuckleScript versions that are at least 3 years old at this point. In my opinion, it feels correct to mark that stability with a v1 release, especially in light of breaking changes that may be coming.

Background

There are some changes in the works (specifically #334, but potentially other upcoming features that leverage newer OCaml/Melnage language features) that will likely break compatibility with BuckleScript. Those changes feel more fitting for a "v2" release, but in order to get to "v2" we should probably mark a "v1" first.

Goals

• Create a 1.0 release that maintains BuckleScript compatibility
• Begin work on v2
• Only update v1 with important bugfixes

Non-Goals

• I don't think we need to pin down any of the specifics of what v2 will look like as part of this RFC
• I don't think this RFC needs to extend to other relude-* libraries (e.g. parse, random, react), but we could have that conversation if it feels appropriate

Solution

• tag the current state of the main branch as v1.0
• push the release to npm
• create a 1.0 branch -- we can cherry-pick important fixes and make additional 1.x releases from there if needed
• open the main branch up for breaking changes

Alternatives

We could instead just say 0.60-whatever-the-current-version-is is the last version to support BuckleScript and call the next breaking changes 1.0. Or we could keep making 0.x releases with breaking changes, and not commit to any v1 or v2 releases. In my opinion, neither of those options accurately reflect the current state of Relude, and they also don't provide very helpful version hints to library users.

Strategy

If approved, I'm happy to own this. It should be pretty easy to do this as early as next weekend, if this is the direction we want to go.

[andywhite37]

This all sounds good to me!

[mlms13]

Upon further thought, releasing a v1 is actually kind of tricky because the tooling in v0.66 aka v1 is... painful. I wasn't able to get esy to build the project locally, so I was having a hard time testing things.

Instead I created a v1 branch, and if we're ever motivated, we can tag a release from that branch someday. But really, I think anyone who is still following this project at this point is likely more interested in a melange/dune/opam compatible version, which is what v2 is (which we'll release very soon).