20310, "e-kayrakli", "What is the process for adding new interface during and after Chapel 2.0 effort?", "2022-07-27T17:39:34Z"
Driving towards Chapel 2.0, and beyond, what should be the process for adding new standard modules or new interface to existing, stable, standard modules?
Should we have all-devs meetings to discuss the new module's design? (Probably)
How about if it is just a function? (Less likely, but where is the line? Probably a case-by-case leadership call)
Should we mark any new interface unstable by default? (Let's not, but might be what we want until there's a better alternative)
Should we introduce a milder version of "unstable" to mark such modules/functions/etc? (Sounds interesting)
Arguably, new things have some unstability because they are not time-tested. No matter how much we discuss their interface, I think we should be more open to changing them in the first couple of releases after their birth.
Maybe we use the word "candidate" and not "unstable"
Maybe we also set a number of releases a candidate remains a candidate.
We document clearly. (both the process and the specific things)
We can add --warn-candidate flag.
Less controversial, but we should advertise the candidate interface and ask for feedback in our typical communication channels.