▼ |  | Unstable: May Change Without Warning

1 | Guidelines for Developing unstable Libraries
2 | Automata: Compiling State Machines
3 | Bytes
4 | Contracts
5 | Converting Values to Strings
6 | Contracts for Macro Subexpressions
7 | Debugging
8 | Definitions
9 | Filesystem
10 | Find
11 | Flonums
12 | Futures
13 | Functions
14 | Hash Tables
15 | Interface-Oriented Programming for Classes
16 | Lazy Require
17 | Lists
18 | Logging
19 | Mark Parameters
20 | Match
21 | Parameter Groups
22 | Pretty-Printing
23 | Sequences
24 | Strings
25 | Structs
26 | Syntax
27 | Temporal Contracts: Explicit Contract Monitors
28 | 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 drracket 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 DrRacket to the unstable collection.

- Put tests in tests/unstable.

Keep documentation and tests up to date.

top← prev up next →