1 |
This file tries to define what we mean when we say Guile is "stable", |
This file tries to define what we mean when we say Guile is "stable", |
2 |
since stability is widely held to be a useful pre-condition for release. |
since stability is widely held to be a useful pre-condition for release. |
3 |
|
|
4 |
|
Basically, stability is a measure of change, so we need to distinguish the |
5 |
|
types of changes that can occur if we want to have fine-grained insight into |
6 |
|
stability. |
7 |
|
|
8 |
|
The type of any particular change is composed of its attributes, which can be |
9 |
|
inferred mostly from "location" and "scope". Here's a list: |
10 |
|
|
11 |
|
- process |
12 |
|
- interface |
13 |
|
- internal |
14 |
|
- documentation |
15 |
|
- code |
16 |
|
- addition |
17 |
|
- removal |
18 |
|
- re-ordering (e.g., procedure args) |
19 |
|
- renaming |
20 |
|
- part-of-LARGER-CHANGE |
21 |
|
- omission |
22 |
|
- commission |
23 |
|
- requires-OTHER-CHANGE |
24 |
|
- [add here] |
25 |
|
|
26 |
|
So for example, writing this document is a change that could be called (typed) |
27 |
|
"addition of process documentation, part of being-more-careful", and we can |
28 |
|
judge how it affects Guile's stability either wholistically ("no worries, let |
29 |
|
the fool blather on -- my program still works") or by examining how certain |
30 |
|
attributes generally affect stability ("no worries, i don't care about process |
31 |
|
anyway"). |