Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] Explore how to roll out experimental features #2676
Capturing the discussion we had so far regarding this experimental feature and turning it in a discussion thread on GitHub for others to chime in.
Why experimental features
While we want to make sure high quality of code goes into our codebase which may take many iterations, releasing the features as
Discussion Topic 1 - Where the experimental code resides or how to indicate as experimental
Proposal 1: Introduce experimental flag
The experimental flag means we release features with different stages like what Node.js does: https://nodejs.org/api/documentation.html#documentation_stability_index
Proposal 2: Encourage composition packages
Create a separate package within the loopback-next monorepo but release only as
Proposal 3: Use master-experimental branch
Proposal 4: a separate monorepo
@dhmlau The experimental flag means we release features with different stages like what Node.js does: https://nodejs.org/api/documentation.html#documentation_stability_index
(@bajtos could correct me if I am wrong) For "Encourage composition packages", my understanding is we treat features as separate modules that's not part of core.
+1, that's my idea too.
IMO, experimental flags is a suboptimal approach as it does not offer enough flexibility both to framework users (they cannot pick a specific version of the experimental feature) and framework maintainers (we have to keep experimental code in our main codebase).
Node.js core is in a different position than we are. Node.js is shipped as a single binary, it is not possible to build a custom Node.js version by combining multiple components. LoopBack is composed from multiple optional building blocks from the beginning, e.g. users can choose to exclude
I'd like us to try to implement as many experimental features as possible in standalone packages.
These two approaches can be combined together:
The more I think about this topic the more reluctant I am to keep experimental code in the main loopback-next monorepo.
The aspect most important to me: how to prevent experiments from negatively effecting our "main" work on production-grade codebase and our milestone plans.
With a new monorepo hosting experimental code, my four concerns are solved:
For experimental features, I think we want to:
With the reasons above, I'd prefer proposal 4. The repo name could be something else, but that's implementation details. :)
@raymondfeng mentioned that setting up automated testing/CI for proposal 4 is more complicated. That might be something to consider too, but I don't have enough knowledge to comment on that.
Let's start with the simplest case here - adding a new module such as
To support this case, we can do the following:
@raymondfeng please expand your proposal to describe how do you envision to address the concerns I raised in my earlier comment.