staging process

[trusktr]

Just starting a discussion here so it can be tracked and not lost in Discord.

I've been wondering if perhaps there can be an official process by which APIs modifications (at least breaking changes) and new additions can be vetted. Perhaps a stage system like in solid-primitives or ECMAScript.

To reword EcmaScript stages, but in relation to Solid Primitives, perhaps something like this:

0. The idea exists (requires only one person to make the idea, and one merge approval), may have any amount of complete or incomplete description, maybe implementation (not required yet), although at this stage no amount of design or implementation is criteria for advancing to the next stage

1. Concensus is made that we may move forward in the idea (by core team). Work starts to get consensus on the API shape (if we haven't already, anyone can participate).

2. At this point, initial API shape consensus is reached (by core team), and we start an implementation (if we haven't already, anyone can try).

3. Implementation is reached (if we haven't already). At this stage, we publish to npm as a pre-release that is still subject to change. Maybe APIs in experimental state are prefixed with experimental in their name, or exported from an experimental folder, to make it clear. At this point we are confident the API will be mostly like what end users will have, but needs testing and verification, and there's a non-zero chance it could change.

At any stage, core may get concensus to downgrade to a lower stage and re-hash ideas.

4. This one is critical, after testing, and usage, we determine we like the API, and finally it goes out of pre-release and is considered stage 4.

[thetarnav]

You said, that there is a way to omit stage 0 (or all pre-stage-3) packages when building & testing. Could you please make a PR with this implemented? It would be very helpful with this staging process, because as I imagine, only the stage 3 package would need to be fully tested.

[trusktr]

Sure, I can once I circle back (solid hack and side projects have me too busy). In the meantime here are the flags for filtering which projects a lerna operates on: https://github.com/lerna/lerna/tree/main/core/filter-options

[trusktr]

Perhaps stage 3 may not require testing (always encouraged of course), but for sure it should be required for stage 4. Stage 4 can be the v1 release along with "fully tested" (we should decide what that means, f.e. 100% code coverage?).

[thetarnav]

Don't know if I get the lerna --ignore filters, but it seams that it only works for filtering by package names.