▼ |  | Unstable

1 | Guidelines for developing unstable libraries
2 | Bytes
3 | Contracts
4 | Exceptions
5 | Lists
6 | Net
7 | Path
8 | Source Locations
9 | Strings
10 | Structs
11 | Syntax
12 | Anaphoric Contracts
13 | Finding Mutated Variables
14 | Find
15 | Interface-Oriented Programming for Classes
16 | Sequences
17 | Hash Tables
18 | Match
19 | Skip Lists
20 | Interval Maps
21 | GUI libraries

top← prev up next →

### 1`` Guidelines for developing unstable libraries

Any collection developer may add modules to the unstable collection.

Every module needs an owner to be responsible for it.

- If you add a module, you are its owner. Add a comment with your name at the top of the module.

- If you add code to someone else’s module, tag your additions with your name. The module’s owner may ask you to move your code to a separate module if they don’t wish to accept responsibility for it.

When changing a library, check all uses of the library in the collections tree and update them if necessary. Notify users of major changes.

Place new modules according to the following rules. (These rules are necessary for maintaining PLT’s separate text, gui, and drscheme distributions.)

- Non-GUI modules go under unstable (or subcollections thereof). Put the documentation in unstable/scribblings and include with include-section from unstable/scribblings/unstable.scrbl.

- GUI modules go under unstable/gui. Put the documentation in unstable/scribblings/gui and include them with include-section from unstable/scribblings/gui.scrbl.

- Do not add modules depending on DrScheme to the unstable collection.

- Put tests in tests/unstable.

Keep documentation and tests up to date.

top← prev up next →