New Issue: What is the process for adding new interface during and after Chapel 2.0 effort?

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.