← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

[merge] bzr.dev

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
38
38
  the user should really pay attention to - which includes trivial shell
39
39
  pipelines.
40
40
 
41
 
  Recommanded values are 
 
41
  Recommended values are 
42
42
    0- OK, 
43
43
    1- Conflicts in merge-like operations, or changes are present in
44
44
       diff-like operations. 
45
45
    2- Unrepresentable diff changes (i.e. binary files that we cannot show 
46
46
       a diff of).
47
 
    3- An error or exception has occured.
 
47
    3- An error or exception has occurred.
48
48
 
49
49
Evolving interfaces
50
50
-------------------
53
53
be sure to change its name as well. For instance, if I add a keyword
54
54
parameter to branch.commit - that's fine. On the other hand, if I add
55
55
a keyword parameter to branch.commit which is a *required* transaction
56
 
object, I should rename the api - i.e. to 'branch.commit_transaction'.
 
56
object, I should rename the API - i.e. to 'branch.commit_transaction'.
57
57
 
58
 
This will prevent users of the old api getting surprising results. 
59
 
Instead, they will get an Attribute error as the api is missing, and
 
58
This will prevent users of the old API getting surprising results. 
 
59
Instead, they will get an Attribute error as the API is missing, and
60
60
will know to update their code. If in doubt, just ask on #bzr.
61
61
 
62
62
Documentation
65
65
If you change the behaviour of a command, please update its docstring
66
66
in bzrlib/commands.py.  This is displayed by the 'bzr help' command.
67
67
 
 
68
NEWS file
 
69
---------
 
70
 
68
71
If you make a user-visible change, please add a note to the NEWS file.
69
72
The description should be written to make sense to someone who's just
70
73
a user of bzr, not a developer: new functions or classes shouldn't be
72
75
bugs should be listed.  See the existing entries for an idea of what
73
76
should be done.
74
77
 
 
78
Within each release, entries in the news file should have the most
 
79
user-visible changes first.  So the order should be approximately:
 
80
 
 
81
 * changes to existing behaviour - the highest priority because the 
 
82
   user's existing knowledge is incorrect
 
83
 * new features - should be brought to their attention
 
84
 * bug fixes - may be of interest if the bug was affecting them, and
 
85
   should include the bug number if any
 
86
 * major documentation changes
 
87
 * changes to internal interfaces
 
88
 
 
89
People who made significant contributions to each change are listed in
 
90
parenthesis.  This can include reporting bugs (particularly with good
 
91
details or reproduction recipes), submitting patches, etc.
75
92
 
76
93
API documentation
77
94
-----------------