|
62464
|
1 How to Maintain Copyright Years for GNU Emacs
|
|
|
2
|
|
|
3
|
|
|
4 Principle: Individual files need to have the year of the release
|
|
|
5 in the copyright notice if there is significant change.
|
|
|
6
|
|
|
7
|
|
|
8 Practice:
|
|
|
9
|
|
|
10 - individual files
|
|
|
11 - each must be examined, along w/ its history, by a human
|
|
|
12 - automated tools facilitate but can never replace this process
|
|
|
13
|
|
|
14 - year of the release
|
|
|
15 - may be different from year of file introduction,
|
|
|
16 or year of last significant change
|
|
|
17 - sometimes the release year slips, leaving a file w/ prematurely
|
|
|
18 marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
|
|
|
19 - intervening years (between releases) are not valid and may cause
|
|
|
20 embarrassment later in case of dispute => remove (however, see next)
|
|
|
21 - years for new files (merged, contributed) that have been separately
|
|
|
22 published are valid even if between releases => leave alone
|
|
|
23
|
|
|
24 - significant change
|
|
|
25 - insignificant
|
|
|
26 - whitespace
|
|
|
27 - copyright notice
|
|
|
28 - version control tags
|
|
|
29 - simple var/func renaming
|
|
|
30 - in-file reorganization/reordering
|
|
|
31 - typos
|
|
|
32 - small bugfixes
|
|
|
33 - small docfixes
|
|
|
34 - filename renaming
|
|
|
35 - most everything else is significant
|
|
|
36 - change to interface
|
|
|
37 - change in functionality
|
|
|
38 - new file
|
|
|
39 - many small changes may be significant in aggregate
|
|
|
40
|
|
|
41 - when in doubt, ask (and update these guidelines -- thanks!)
|
|
|
42
|
|
|
43 - sometimes people make mistakes
|
|
|
44 - if they have not read these guidelines, point them here
|
|
|
45 - if the guidelines are not helpful, improve the guidelines
|
