Skip to content

doc: revise Introducing New Modules #25975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

doc: revise Introducing New Modules #25975

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 13 additions & 15 deletions COLLABORATOR_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -292,25 +292,23 @@ metadata. Raise a Pull Request like any other change.

### Introducing New Modules

Semver-minor commits that introduce new core modules should be treated with
extra care.
Treat commits that introduce new core modules with extra care.
Copy link
Member

@richardlau richardlau Feb 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it mentioned elsewhere that introducing a new core module is semver-minor?
Copy link
Member Author

@Trott Trott Feb 7, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not as far as I know. If it's desirable to have it here, I can add a sentence. I'd prefer to leave it out as it's self-evident and low-value (as someone else will certainly add the label if the author does not) and this doc is plenty long as it is. But I don't have a strong preference, so I'll yield if a Collaborator thinks it needs to be in there.
Copy link
Member

@richardlau richardlau Feb 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have a strong preference either. I guess if we do mention it it can go in the bullet list below (probably next to "Label with the tsc-review label.").
Copy link
Contributor

@Fishrock123 Fishrock123 Feb 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By definition it adds functionality, ergo, semver-minor.

The name of the new core module should not conflict with any existing
module in the ecosystem unless a written agreement with the owner of those
modules is reached to transfer ownership.
Check if the module's name conflicts with an existing ecosystem module. If it
does, choose a different name unless the module owner has agreed in writing to
transfer it.

If the new module name is free, a Collaborator should register a placeholder
in the module registry as soon as possible, linking to the pull request that
introduces the new core module.
If the new module name is free, register a placeholder in the module registry as
soon as possible. Link to the pull request that introduces the new core module
in the placeholder's `README`.

Pull requests introducing new core modules:
For pull requests introducing new core modules:

* Must be left open for at least one week for review.
* Must be labeled using the `tsc-review` label.
* Must have signoff from at least two TSC members.

New core modules must be landed with a [Stability Index][] of Experimental,
and must remain Experimental until a semver-major release.
* Allow at least one week for review.
* Label with the `tsc-review` label.
* Land only after sign-off from at least two TSC members.
* Land with a [Stability Index][] of Experimental. The module must remain
Experimental until a semver-major release.

### Additions to N-API

Expand Down